Cisco PIX - regelmäßiger Tunnel reset notwendig
Diese Frage richtet sich an alle Cisco Experten, welche hoffentlich eine Idee für mich parat haben.
Wir haben in unserem Netz diverse Außenlokationen welche über einen VPN Tunnel miteinander verbunden sind. An beiden Seiten wird diese Verbindung über eine Cisco PIX initiiert.
Auf einer Seite kommt eine Cisco Pix PIX-506E und auf der anderen eine Cisco PIX-515E zum Einsatz.
Das VPN ist folgendermaßen konfiguriert:
PIX1
crypto map outside_map 40 ipsec-isakmp
crypto map outside_map 40 match address outside_cryptomap_40
crypto map outside_map 40 set peer xxx.xxx.xxx.xxx
crypto map outside_map 40 set transform-set ESP-AES-256-MD5
isakmp key address xxx.xxx.xxx.xxx netmask 255.255.255.255 no-xauth no-config-mode
PIX2
crypto map outside_map 10 ipsec-isakmp
crypto map outside_map 10 match address outside_cryptomap_10
crypto map outside_map 10 set peer xxx.xxx.xxx.xxx
crypto map outside_map 10 set transform-set ESP-AES-256-MD5
isakmp key address xxx.xxx.xxx.xxx netmask 255.255.255.255 no-xauth no-config-mode
Nun passiert es regelmäßig, das die Verbindung über den Tunnel abbricht, so dass dieser über den Befehl "clear crypto ipsec sa peer xxx.xxx.xxx.xxx" zurückgesetzt werden muss.
Hat vielleicht jemand eine Idee, wie man den regelmäßig sporadisch auftredenden Verbindungsabbruch verhindern kann?
Besten Dank schon mal im Voraus!
Wir haben in unserem Netz diverse Außenlokationen welche über einen VPN Tunnel miteinander verbunden sind. An beiden Seiten wird diese Verbindung über eine Cisco PIX initiiert.
Auf einer Seite kommt eine Cisco Pix PIX-506E und auf der anderen eine Cisco PIX-515E zum Einsatz.
Das VPN ist folgendermaßen konfiguriert:
PIX1
crypto map outside_map 40 ipsec-isakmp
crypto map outside_map 40 match address outside_cryptomap_40
crypto map outside_map 40 set peer xxx.xxx.xxx.xxx
crypto map outside_map 40 set transform-set ESP-AES-256-MD5
isakmp key address xxx.xxx.xxx.xxx netmask 255.255.255.255 no-xauth no-config-mode
PIX2
crypto map outside_map 10 ipsec-isakmp
crypto map outside_map 10 match address outside_cryptomap_10
crypto map outside_map 10 set peer xxx.xxx.xxx.xxx
crypto map outside_map 10 set transform-set ESP-AES-256-MD5
isakmp key address xxx.xxx.xxx.xxx netmask 255.255.255.255 no-xauth no-config-mode
Nun passiert es regelmäßig, das die Verbindung über den Tunnel abbricht, so dass dieser über den Befehl "clear crypto ipsec sa peer xxx.xxx.xxx.xxx" zurückgesetzt werden muss.
Hat vielleicht jemand eine Idee, wie man den regelmäßig sporadisch auftredenden Verbindungsabbruch verhindern kann?
Besten Dank schon mal im Voraus!
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 130096
Url: https://administrator.de/contentid/130096
Ausgedruckt am: 25.11.2024 um 17:11 Uhr
4 Kommentare
Neuester Kommentar
Hallo,
der Vorschlag von Komabaer ist sicher nicht verkehrt, aber dafür müsste man mal wissen was du überhaupt für eine IOS Version verwendest.
Bricht nur ein bestimmter Tunnel weg, oder sind es verschiedene, oder alle?
Ich habe mir mal Freihait genommen aus einem anderen Beitrag hier im Forum etwas rauszukopieren
(Einen Dank an Spacyfreak):
3. VPN Troubleshooting:
Lass die Befehle mal mitlaufen (Danach aber ein "undebug all" nicht vergessen.)
Nicht das es "nur" daran liegt das der Provider Probleme hat.
brammer
der Vorschlag von Komabaer ist sicher nicht verkehrt, aber dafür müsste man mal wissen was du überhaupt für eine IOS Version verwendest.
Bricht nur ein bestimmter Tunnel weg, oder sind es verschiedene, oder alle?
Ich habe mir mal Freihait genommen aus einem anderen Beitrag hier im Forum etwas rauszukopieren
(Einen Dank an Spacyfreak):
3. VPN Troubleshooting:
- debug crypto isakmp 7 (Zeigt in Echtzeit an wie der VPN Tunnel aufgebaut wird, IKE Phase1)
- debug crypto ipsec 7 (Zeig in Echtzeit IKE Phase 2 an)
- no debug crypto isakmp (Nach Fehlersuche wieder debug abschalten!)
- no debug crypto ipsec (Nach Fehlersuche wieder debug abschalten!)
Lass die Befehle mal mitlaufen (Danach aber ein "undebug all" nicht vergessen.)
Nicht das es "nur" daran liegt das der Provider Probleme hat.
brammer