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

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

Ich habe den Parameter gefunden - DANKE
Mal sehen, wie es sich jetzt verhält

Passt die o.g. Konfiguration sonst ?

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 ?

An sowas dachte ich auch schon - gibt es eine Möglichkeit die Broadcast Meldungen durchzulassen ?

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.

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