torstene
Goto Top

OpenCom 1010 - VPN - OpenPhone 65 IP - Verbindung bricht ab

Guten Morgen,

ich haben OP 65 IP per VPN an die OpenCom angeschlossen. Nach dem Start des Gerätes läuft alles wunderbar. (Holt sich die Software, registriert sich usw..)

Wird am Endgeräte eine Std. nicht telefoniert, lässt es sich danach nicht mehr anrufen.
Kommt der 1. Anruf an das Gerät führt es eine "Registrierung" durch. D.h. der Anruf geht ins Leere.
Wird danach sofort wieder angerufen, kann ich das Gespräch entgegen nehmen,
ABER ich kann vom Endgerät nicht wegtelefonieren.

Strom raus, Gerät startet neu, alles wieder normal.

Ich vermute mal, dass irgend welche Verbindungsdaten zwischen OpenCom und OpenPhone "fehlen."

Die VPN wird mit 2 Cisco ASA 5505 hergestellt, es wird das gesammte IP-Protokoll geroutet. Die Verbindung zwischen den Routern ist eine Standleitung, also an dieser kann es definitiv nicht liegen.

Torsten.E

Content-ID: 170691

Url: https://administrator.de/forum/opencom-1010-vpn-openphone-65-ip-verbindung-bricht-ab-170691.html

Ausgedruckt am: 21.12.2024 um 18:12 Uhr

brammer
brammer 31.07.2011 um 11:18:06 Uhr
Goto Top
Hallo,

gilt das auch wenn anderer Traffic über den Tunnel läuft?

Wenn der Tunnel ohne Traffic nach 60 munuten abgebaut wird, hast du vermutlich ein IDLE Timeout eingestellt. (Der Default Wert sollte bei 30 min liegen.)

vpn-idle-timeout:

To configure a user timeout period use the vpn-idle-timeout command in group-policy configuration mode or in username configuration mode. If there is no communication activity on the connection in this period, the security appliance terminates the connection.

To remove the attribute from the running configuration, use the no form of this command. This option allows inheritance of a time-out value from another group policy. To prevent inheriting a value, use the vpn-idle-timeout none command.

vpn-idle-timeout {minutes | none}

no vpn-idle-timeout

Specifies the number of minutes in the timeout period. Use an integer between 1 and 35791394.

Uses the global WebVPN default-idle-timeout value (seconds) from the command: hostname(config-webvpn)# default-idle-timeout
The range for this value in the WebVPN default-idle-timeout command is 60-86400 seconds; the default Global WebVPN Idle timeout in seconds -- default is 1800 seconds (30 min).

brammer
TorstenE
TorstenE 31.07.2011 um 11:29:02 Uhr
Goto Top
Hier mal die Konfiguration.

Saved

ASA Version 8.3(1)
!
hostname ciscoasa
domain-name default.domain.invalid
enable password 8Ry2YjIyt7RRXU24 encrypted
passwd 2KFQnbNIdI.2KYOU encrypted
names
!
interface Vlan1
description Maria Thann
nameif inside
security-level 100
ip address 192.168.21.253 255.255.255.0
!
interface Vlan2
description Internet
nameif outside
security-level 0
ip address 217.199.201.197 255.255.255.248
!
interface Ethernet0/0
switchport access vlan 2
!
interface Ethernet0/1
!
interface Ethernet0/2
!
interface Ethernet0/3
!
interface Ethernet0/4
!
interface Ethernet0/5
!
interface Ethernet0/6
!
interface Ethernet0/7
!
boot system disk0:/asa813-k8.bin
ftp mode passive
dns server-group DefaultDNS
domain-name default.domain.invalid
object network obj_any
subnet 0.0.0.0 0.0.0.0
object network Maria-Thann
subnet 192.168.21.0 255.255.255.0
object network Mellatz
subnet 192.168.20.0 255.255.255.0
access-list outside_access_in extended permit icmp any any echo
access-list outside_access_in extended permit icmp any any echo-reply
access-list outside_1_cryptomap extended permit ip object Maria-Thann object Mellatz
access-list inside_access_in extended permit ip any any
pager lines 24
logging enable
logging asdm informational
mtu inside 1500
mtu outside 1500
icmp unreachable rate-limit 1 burst-size 1
asdm image disk0:/asdm-631.bin
no asdm history enable
arp timeout 14400
nat (inside,outside) source static Maria-Thann Maria-Thann destination static Mellatz Mellatz
!
object network Maria-Thann
nat (inside,outside) dynamic interface
access-group inside_access_in in interface inside
access-group outside_access_in in interface outside
route outside 0.0.0.0 0.0.0.0 217.199.201.193 1
route outside 0.0.0.0 0.0.0.0 217.199.201.198 tunneled
timeout xlate 3:00:00
timeout conn 1:00:00 half-closed 0:10:00 udp 0:02:00 icmp 0:00:02
timeout sunrpc 0:10:00 h323 0:05:00 h225 1:00:00 mgcp 0:05:00 mgcp-pat 0:05:00
timeout sip 0:30:00 sip_media 0:02:00 sip-invite 0:03:00 sip-disconnect 0:02:00
timeout sip-provisional-media 0:02:00 uauth 0:05:00 absolute
timeout tcp-proxy-reassembly 0:01:00
dynamic-access-policy-record DfltAccessPolicy
http server enable
http 192.168.21.0 255.255.255.0 inside
no snmp-server location
no snmp-server contact
snmp-server enable traps snmp authentication linkup linkdown coldstart
crypto ipsec transform-set ESP-AES-256-MD5 esp-aes-256 esp-md5-hmac
crypto ipsec transform-set ESP-DES-SHA esp-des esp-sha-hmac
crypto ipsec transform-set ESP-DES-MD5 esp-des esp-md5-hmac
crypto ipsec transform-set ESP-AES-192-MD5 esp-aes-192 esp-md5-hmac
crypto ipsec transform-set ESP-3DES-MD5 esp-3des esp-md5-hmac
crypto ipsec transform-set ESP-AES-256-SHA esp-aes-256 esp-sha-hmac
crypto ipsec transform-set ESP-AES-128-SHA esp-aes esp-sha-hmac
crypto ipsec transform-set ESP-AES-192-SHA esp-aes-192 esp-sha-hmac
crypto ipsec transform-set ESP-AES-128-MD5 esp-aes esp-md5-hmac
crypto ipsec transform-set ESP-3DES-SHA esp-3des esp-sha-hmac
crypto ipsec security-association lifetime seconds 28800
crypto ipsec security-association lifetime kilobytes 4608000
crypto map outside_map 1 match address outside_1_cryptomap
crypto map outside_map 1 set pfs group1
crypto map outside_map 1 set peer 217.199.201.198
crypto map outside_map 1 set transform-set ESP-3DES-SHA
crypto map outside_map 1 set security-association lifetime seconds 86400
crypto map outside_map 1 set security-association lifetime kilobytes 2147483647
crypto map outside_map interface outside
crypto isakmp enable outside
crypto isakmp policy 5
authentication pre-share
encryption 3des
hash sha
group 2
lifetime 86400
crypto isakmp policy 10
authentication pre-share
encryption des
hash sha
group 2
lifetime 86400
telnet timeout 5
ssh timeout 5
console timeout 0
dhcpd auto_config outside
!

threat-detection basic-threat
threat-detection statistics access-list
no threat-detection statistics tcp-intercept
webvpn
tunnel-group 217.199.201.198 type ipsec-l2l
tunnel-group 217.199.201.198 ipsec-attributes
pre-shared-key *
!
!
prompt hostname context
call-home
profile CiscoTAC-1
no active
destination address http https://tools.cisco.com/its/service/oddce/services/DDCEService
destination address email callhome@cisco.com
destination transport-method http
subscribe-to-alert-group diagnostic
subscribe-to-alert-group environment
subscribe-to-alert-group inventory periodic monthly
subscribe-to-alert-group configuration periodic monthly
subscribe-to-alert-group telemetry periodic daily
Cryptochecksum:f2282dbe94f8a27dbb6425f04a31ae97
: end
asdm image disk0:/asdm-631.bin
no asdm history enable
TorstenE
TorstenE 31.07.2011 um 11:58:20 Uhr
Goto Top
Ich habe den Parameter gefunden - DANKE
Mal sehen, wie es sich jetzt verhält

Passt die o.g. Konfiguration sonst ?
TorstenE
TorstenE 31.07.2011 um 12:52:04 Uhr
Goto Top
OK jetzt eine Stund später.

Der Tunnel war die ganze Zeit aufrecht, also immer wieder Traffic.
Das IP-Telefon wurde jetzt eine Stunde nicht angefasst, wollte telefonieren - Ende, musste neuen Reset am Tel. machen.

Also am Tunnel in Form von Verbindungsabbruch liegt es nicht.

Kann es sein, dass im "Standard"-Tunnel bestimmte IP-Packet vielleicht nicht weitergeleitet werden, welche aber für so ein Telefon notwendig sind ?
brammer
brammer 31.07.2011 um 18:07:43 Uhr
Goto Top
Hallo,

Broadcast Pakete werde typischerweise nicht weitergeleitet. Stichwort Broadcast Domain.

Es kommt darafu an was das Telefon für Pakete erwartet.
Einfacher mal einen Wireshark ans Telefon hängen und schauen was für Pakete gesendet und empfangen werden.

brammer
TorstenE
TorstenE 31.07.2011 um 18:29:37 Uhr
Goto Top
An sowas dachte ich auch schon - gibt es eine Möglichkeit die Broadcast Meldungen durchzulassen ?
TorstenE
TorstenE 31.07.2011 um 18:37:19 Uhr
Goto Top
Hier ein Ausschnitt aus einem anderen Forum, welchen in gerade gefunden habe. Er beschreibt das Problem ganz genau.
Gibt es zu der unten aufgeführten Einstellung "Connection Tracker bzw. State Table Timeout für hängende Sessions" eine Alternative bzw. gibt es das im Cisco ebenfalls ?

Gruss

Torsten


<-----------------


Hallo Balogh,

endlich ein Leidensgenosse (Leider)!
Ich hatte die Hoffnung schon aufgegeben.

Ich habe das gleiche Problem. Ich setzte seit Jahren bei meinen Kunden Router der Firma Bintec (jetzt Funkwerk) ein. Diese verbinden Standorte per VPN über IPsec.

Die Tunnel laufen einwandfrei, keinerlei Programme (z.B. RDP) haben Probleme.
Die IP-Systemtelefone OpenPhone 6x und 7x, sowie die Softphones haben alle
während Gesprächen eine gute Sprachqualität und keinerlei Probleme, ausser....

Nach einer nicht genau definierbaren Zeit der "Nichtbenutzung", schlafen die Geräte ein.
D.h., dass Telefon steht auf dem Tisch und erweckt den Anschein das alles OK ist,
aber es kommen keine Rufe mehr an und wenn man selbst Telefonieren will passiert nichts. Manchmal bemerkt das Gerät dann seine "Nichtfunktion" und macht einen Neustart. In der Regel muss man diesen jedoch durch "Stromsteckerziehen" herbeiführen.

An dieser Stelle die Bemerkung: Die DECT over IP Basis und auch die Aastra 5x SIP Telefone funktionieren einwandfrei und zwar zur selben Zeit, über den selben Tunnel!!??

Die DeTeWe-Hotline meinte, ich solle den Netzwerkverkehr mit Wireshark aufzeichnen und Ihnen zur Auswertung zukommen lassen.

Da ich mich mit Protokollanalyse aber bislang nicht beschäftigt habe, fehlt mir momentan die Zeit das erforderliche Scenario aufzubauen und diese Geschichte durchzuführen.

Ich habe das auch schon mit der Routerkonstellation:

Bintec <-> Bintec
Bintec <-> Zywall USG100
Bintec <-> Lancom

getestet und zwar mit dem gleichen, schlechten Ergebniss.

Wenn Du jetzt sagst, dass es mit Zyxel <-> Zyxel auch nicht geht,
dann kann ich Bintec wohl nicht mehr die Schuld geben und eher das Problem
im DeTeWe Verbindungsprotokoll suchen.

Der Gedankengang ist inzwischen soweit gereift, dass das Problem durch die in den
Routern vorhandene SIF (StatefullInspectionFirewall) hervorgerufen wird.

Laienhaft ausgedrückt würde ich annehmen, die SIF macht nach einer gewissen Zeit
die Session/Port dicht und die Telefone versuchen nicht ernergisch genug die Anlage
wieder zufinden. Was dann dazu führt, dass diese die Geräte als nicht verfügbar an sieht.

Im übrigen ist es Egal welche OpenCom 100/X320 Du nimmst, dass Problem tritt bei allen
auf.


Gruß

Christian




Balogh

19.12.2009, 14:41

In diesem Forum wurde dann und wann von Reboots auf IP-Endgeräten in VPN-Netzwerken berichtet. Diese erfolgen immer nach dem gleichen Muster: nach einer gewissen Zeit der Inaktivität (keine Gespräche, kein LED-Zustandswechsel, kein Anruf) löst das Hörerabnehmen, ein Tastendruck oder ein eingehender Anruf einen Reboot auf ebendiesem IP-Endgerät aus. Beim OpenPhone 75IP wird beispielsweise auf dem Display angezeigt:

IP PHONE terminated
IP PHONE module load
IP PHONE application start
please wait
starting protocol

Danach ist das Endgerät wieder bereit. Ein allfälliger Anruf ist aber bereits verpasst; er ist aber in der Anrufliste protokolliert. Weil das Problem nur dann auftritt, wenn das Endgerät per VPN angeschlossen ist, fiel der Verdacht natürlich sofort auf die VPN-Router. Es zeigte sich, dass die Probleme mit Firewalls verschiedener Hersteller auftreten, aber nach unterschiedlichen Wartezeiten.

Bei Firewalls vom Typ ZyXEL ZyWALL tritt das Problem alle 2.5 Stunden auf. Die Zeit von 9000 Sekunden entspricht dem Connection Tracker bzw. State Table Timeout für hängende Sessions. Der Workaround besteht darin, dass diese Zeit erhöht wird. Bei der aktuellen ZyXEL ZyWALL USG-Serie lässt sich der Wert bis auf 432000 Sekunden erhöhen, was fünf Tagen entspricht. Dadurch wird die Wahrscheinlichkeit eines Reboots praktisch auf 0 reduziert.

Bei anderen Firewall-Herstellern ist die Zeit sogar kürzer als 9000 Sekunden und führt dazu, dass die Reboots tendenziell noch häufiger auftreten können.

Die beste Lösung wäre freilich, wenn Aastra ihr eigenes VoIP-Protokoll so anpassen könnte, dass es "firewallfreundlicher" wäre. Denn das beidseitige Deaktiveren aller Firewall-Funktionen, was einem zweiten funktionierenden Workaround bei ZyXEL ZyWALL-Geräten entspricht, kann ja keine praktikable Lösung sein.
TorstenE
TorstenE 01.08.2011 um 20:23:50 Uhr
Goto Top
Ich habe ein wenig gesucht. Ist das die Einstellung, mit welcher ich das Problem beheben kann ?

access-list inside_mpc extended permit ip object OpenPhone-159 object OpenCom-1010
access-list inside_mpc extended permit ip object OpenCom-1010 object OpenPhone-159

class-map inside-class-OpenPhone
match access-list inside_mpc

policy-map DCD-fue-OpenPhone
description Damit die Sessions der Telefone nicht abbrechen
class inside-class-OpenPhone
set connection timeout idle 1:00:00 dcd 0:15:00 5

service-policy DCD-fue-OpenPhone interface inside
prompt hostname context
call-home
profile CiscoTAC-1
no active
destination address http https://tools.cisco.com/its/service/oddce/services/DDCEService
destination address email callhome@cisco.com
destination transport-method http
subscribe-to-alert-group diagnostic
subscribe-to-alert-group environment
subscribe-to-alert-group inventory periodic monthly
subscribe-to-alert-group configuration periodic monthly
subscribe-to-alert-group telemetry periodic daily
Cryptochecksum:83aab1fd09fd8e4e01cb0b7f72ea0baf


Verstehe das so, dass praktisch alle 15 Minuten nachgeschaut wird, ob die Session noch da ist, wenn nein, wird diese Abfrage 5 mal wiederholt, würde ich damit auf 2.5 Std. kommen. Wenn dann keiner der Teilnehmer antwortet wird Session gelöscht ?

Torsten.E
brammer
brammer 01.08.2011 um 20:51:03 Uhr
Goto Top
Hallo,

ich habe mal in der Command Reference der ASA nachgelesen:

embryonic
hh:mm:ss
Sets the timeout period until a TCP embryonic (half-open) connection is closed,
between 0:0:5 and 1193:0:0. The default is 0:0:30. You can also set the value to
0, which means the connection never times out. A TCP connection for which a
three-way handshake is not complete is an embryonic connection.

Seite 2388

Wenn du den Timeout auf 0 setzt Timed die Verbindung nicht aus...
Damit dürfte dir mehr geholfen sein als mit einer Regelmässigen Prüfung.
Es sei denn du kannst dein Open Com dazu bringen regelmässig ein keep alive zu senden

brammer