Abbruch eines Site to Site VPN Tunnel zw. zwei Cisco ASA 5505
Hallo Community,
ich habe eine Problem mit einem Site to Site VPN Tunnel.
Zw. zwei Standorten kommt es nach ca. 24 Stunden zum Abbruch des Site to Site VPN Tunnels. Dieser wird zw. zwei baugleichen Cisco ASA 5505 (50 Hosts) betrieben.
Die Kommunikation zw. zwei Standorten funktioniert an sich problemlos in beide Richtungen. Nach dem Abbruch wird der Tunnel nicht mehr aufgebaut. Im Log werden nach einiger Zeit folgende Meldungen protokolliert, sobald ich den Aufbau des Tunnels mit einem Ping anstoße:
1: Jan 25 2014 | 16:52:16 Local:111.111.111.111:500 Remote:222.222.222.222:500 Username:222.222.222.222 Negotiation aborted due to ERROR: Maximum number of retransmissions reached
2: Jan 25 2014 | 16:52:16 IKEv2 was unsuccessful at setting up a tunnel. Map Tag = outside_map. Map Sequence Number = 1.
3: Jan 25 2014 | 16:52:16 Tunnel Manager dispatching a KEY_ACQUIRE message to IKEv1 after a failed attempt.. Map Tag = outside_map. Map Sequence Number = 1.
Einige Momente später wird dann protokolliert:
4: Jan 25 2014 | 17:22:48 IKEv1 was unsuccessful at setting up a tunnel. Map Tag = outside_map. Map Sequence Number = 1.
5: Jan 25 2014 | 17:22:48´Tunnel Manager has failed to establish an L2L SA. All configured IKE versions failed to establish the tunnel. Map Tag= outside_map. Map Sequence Number = 1.
Standort 111.111.111.111: VDSL
Standort 222.222.222.222: ADSL2+
Beide Standorte haben eine statische WAN IP-Adresse.
Mehrere IOS Updates an beiden Standorten (verschiedene Images in Version 8 sowie die aktuellste 9.1) haben keine Veränderung gebracht, auch der Tausch der ASAs nicht.
Google hat leider keine brauchbaren Ergebnisse zu den oben genannten Logs gebracht. Bei anderen Kunden sind auch Site to Site VPN Tunnel in Betrieb, mit gleicher Konfiguration, jedoch ohne dieses Problem. Auch ein Vergleich der Konfiguration zw. diesem und den anderen Kunden hat keine Unterschiede hervorgetan, bis auf notwendigen Unterschiede.
Dieses Problem ist bisher noch nirgends aufgetreten. Bei diesem Kunden hier allerdings sofort.
Hat jemand dazu eine Idee?
ich habe eine Problem mit einem Site to Site VPN Tunnel.
Zw. zwei Standorten kommt es nach ca. 24 Stunden zum Abbruch des Site to Site VPN Tunnels. Dieser wird zw. zwei baugleichen Cisco ASA 5505 (50 Hosts) betrieben.
Die Kommunikation zw. zwei Standorten funktioniert an sich problemlos in beide Richtungen. Nach dem Abbruch wird der Tunnel nicht mehr aufgebaut. Im Log werden nach einiger Zeit folgende Meldungen protokolliert, sobald ich den Aufbau des Tunnels mit einem Ping anstoße:
1: Jan 25 2014 | 16:52:16 Local:111.111.111.111:500 Remote:222.222.222.222:500 Username:222.222.222.222 Negotiation aborted due to ERROR: Maximum number of retransmissions reached
2: Jan 25 2014 | 16:52:16 IKEv2 was unsuccessful at setting up a tunnel. Map Tag = outside_map. Map Sequence Number = 1.
3: Jan 25 2014 | 16:52:16 Tunnel Manager dispatching a KEY_ACQUIRE message to IKEv1 after a failed attempt.. Map Tag = outside_map. Map Sequence Number = 1.
Einige Momente später wird dann protokolliert:
4: Jan 25 2014 | 17:22:48 IKEv1 was unsuccessful at setting up a tunnel. Map Tag = outside_map. Map Sequence Number = 1.
5: Jan 25 2014 | 17:22:48´Tunnel Manager has failed to establish an L2L SA. All configured IKE versions failed to establish the tunnel. Map Tag= outside_map. Map Sequence Number = 1.
Standort 111.111.111.111: VDSL
Standort 222.222.222.222: ADSL2+
Beide Standorte haben eine statische WAN IP-Adresse.
Mehrere IOS Updates an beiden Standorten (verschiedene Images in Version 8 sowie die aktuellste 9.1) haben keine Veränderung gebracht, auch der Tausch der ASAs nicht.
Google hat leider keine brauchbaren Ergebnisse zu den oben genannten Logs gebracht. Bei anderen Kunden sind auch Site to Site VPN Tunnel in Betrieb, mit gleicher Konfiguration, jedoch ohne dieses Problem. Auch ein Vergleich der Konfiguration zw. diesem und den anderen Kunden hat keine Unterschiede hervorgetan, bis auf notwendigen Unterschiede.
Dieses Problem ist bisher noch nirgends aufgetreten. Bei diesem Kunden hier allerdings sofort.
Hat jemand dazu eine Idee?
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 227750
Url: https://administrator.de/contentid/227750
Ausgedruckt am: 19.11.2024 um 09:11 Uhr
17 Kommentare
Neuester Kommentar
kommt es nach ca. 24 Stunden zum Abbruch des Site to Site VPN Tunnels.
Das ist normal wenn du DSL mit der täglichen Zwangstrennung verwendest. Hast du das berücksichtigst ?Nach dem Abbruch wird der Tunnel nicht mehr aufgebaut.
Das ist nicht normal und zeugt von einem Konfigurationsfehler in der ASADie Retransmissions zeigen das die eine Seite gar nicht da ist oder nicht antwortet. Da kann man ohne detailiertere Info hier nur stundelang im freien Fall raten...
Oft ist der Grund eine Router Kaskade, also wenn vor das ASA noch ein weiterer NAT Router ist ohne korrektes Port Forwarding für IPsec VPNs die deinen ASA macht (Ports UDP 500, UDP 4500, und ESP Protokoll)
An der IOS Firmware oder gar an der HW liegt das auch niemals. Die Tauscherei ist eher hilfloses Gefrickel und in der Regel sinnlos wie auch hier.
Der Fehler liegt irgendwo in der Konfig vermutlich aber im fehlerhaften Netzdesign einer der beiden Seiten oder sogar beider ?!
Ohne einen Konfig Auszug oder einer Designzeichnung oder Beschreibung ist einen zielführende Hilfe aber unmöglich.
Teilkonfigs und einige Grundlageninfos erklären diese Tutorials:
IPSEC Protokoll - Einsatz, Aufbau, benötigte Ports und Begriffserläuterungen
Cisco PIX Firewall IPsec VPN Tunnel auf pfsense Firewall
und
IPsec VPNs einrichten mit Cisco, Mikrotik, pfSense Firewall, FritzBox, Smartphone sowie Shrew Client Software
Hallo,
DynDNS Probleme
IPs haben sich irgendwo geändert
Gruß,
Peter
Zitat von @mcgiga:
ich kann den Tunnel so oft manuell trennen wie ich möchte, trotzdem kann er immer wieder aufgebaut werden
Das heisst doch das zu diesem Zeitpunkt deine entfernten Endpunkte den Routern dann noch bekannt sind.ich kann den Tunnel so oft manuell trennen wie ich möchte, trotzdem kann er immer wieder aufgebaut werden
Sobald jedoch die Zwangstrennung die Unterbrechung verursacht, lässt sich der Tunnel nicht mehr aufbauen,
DNS ProblemeDynDNS Probleme
IPs haben sich irgendwo geändert
nachdem ich die ASA am Standort 111.111.111.111 neu starte.
Siehe oben. Namens oder IP probleme bzw. nicht bekanntDas Netz in dieser Form mit dem Site to Site Tunnel ist bei zig Kunden im Einsatz
Dann solltest du doch Verstehen das wir ohneIinformationen zu deinen Netzaufbau und Konfigurationen zwar mit dir gemeinsam heulen und weinen können, aber dir nicht wirklich helfen können.Daher ist es auch so merkwürdig, dass nur hier dieses Problem auftritt
Na, weil da eben etwas anders bzw. Falsch ist.Dann greifst du zwangsläufig zu einer anderen IOS Version, um auch diese ausschließen zu können.
Warum`Andere Standorte und netzen laufen doch mit den gleichen geräten und gleichen IOS Versionen ohen Probleme. Dann müssten die doch auch eben nicht gehen.Gruß,
Peter
Hallo,
Dein Problem heißt in Wirklichkeit Synchronisation und zwar die des Routers mit dem
DynDNS Zugang. Damit die neue IP Adresse auch bekannt ist und die Verbindung wieder
aufgebaut werden kann.
Gruß
Dobby
Dein Problem heißt in Wirklichkeit Synchronisation und zwar die des Routers mit dem
DynDNS Zugang. Damit die neue IP Adresse auch bekannt ist und die Verbindung wieder
aufgebaut werden kann.
Gruß
Dobby
Nur nochmal dumm nachgefragt:
Nur um technisch ganz sicher zu gehen....
2.) Der Provider an "Local:111.111.111.111" ist der identisch zu dem am anderen Standort ?
3.) Wenn nein, hast du über diesen Provider noch andere Kunden VPNs am laufen oder passiert dies nur bei diesem einzigen Provider ?
4.) Im Zweifel ist es sinnvoll den VPN Verbindungsaufbau nach einem dieser Hänger mal mit dem Wireshark anzusehen um mal ganz genau zu sehen WER hier Pakete nicht weiterleitet oder WO Antworten fehlen oder ins Leere laufen.
Blind getippt scheint es was mit dem spezifischen Provider zu tun zu haben wenn dieses VPN Konzept so fehlerlos mit anderen Kundennetzen rennt.
Standort 111.111.111.111: lokales Netz 192.168.0.0
VDSL Modem <-> ASA 5505
Standort 222.222.222.222: lokales Netz 192.168.2.0
ADSL Modem <-> ASA5505
1.) Die dort zitierten "Modems" sind das wirklich rein nur Modems, also reine Medienwandler (die ASA hält die öffentliche Provider IP Adresse !) oder sind das NAT Router die vor das ASA liegen ?VDSL Modem <-> ASA 5505
Standort 222.222.222.222: lokales Netz 192.168.2.0
ADSL Modem <-> ASA5505
Nur um technisch ganz sicher zu gehen....
2.) Der Provider an "Local:111.111.111.111" ist der identisch zu dem am anderen Standort ?
3.) Wenn nein, hast du über diesen Provider noch andere Kunden VPNs am laufen oder passiert dies nur bei diesem einzigen Provider ?
4.) Im Zweifel ist es sinnvoll den VPN Verbindungsaufbau nach einem dieser Hänger mal mit dem Wireshark anzusehen um mal ganz genau zu sehen WER hier Pakete nicht weiterleitet oder WO Antworten fehlen oder ins Leere laufen.
Blind getippt scheint es was mit dem spezifischen Provider zu tun zu haben wenn dieses VPN Konzept so fehlerlos mit anderen Kundennetzen rennt.
Hallo,
Welche anderen Standorte hast du bei deinen Kunden welche auch mit VDSL des gleichen ISP Arbeitet wo auch das gleiche Modem und ASA in gleicher Konfiguration verwendest (ADSL <> VDSL)? Was ergibt ein Vergleich mit deren Konfiguration(en)?
Was sagt ein Wireshark auf der Verbindung zwischen Modem und ASA?
Gruß,
Peter
Zitat von @mcgiga:
Selbige Modems sind auch bei anderen Kunden im Einsatz
zu 2.: ja, an beiden Standorten ist es ein Anschluss der Telekom (VDSL, ADSL).
Was denn jetzt? ADSL und VDSL am gleichen Anschluss? Und deinerste Antwort lässt uns zu den Gedanken kommen das du sowohl für ADSL und VDSL die gleichen Modems verwendest, oder? Das Modell und Hersteller ist ein Betriebsgeheimnis oder warum nennst du die nicht?Selbige Modems sind auch bei anderen Kunden im Einsatz
zu 2.: ja, an beiden Standorten ist es ein Anschluss der Telekom (VDSL, ADSL).
Als nächstes muss ich wohl mal das VDSL Modem tauschen
Zudem hilft auch nur ein Neustart der ASA am Standort 111.111.111.111 (VDSL).
Das bedeutet das dort das VDSL Modem und deine ASA gleichzeitig kaputt sind. Warum das Modem tauschen wenn nur ein Neustart der ASA hilft? Das deutet auf eine Fehler in der Hardware der ASA hin oder eben falsche Konfiguration. Die Unterschiede VDSL und ADSL sind die bekannt?Zudem hilft auch nur ein Neustart der ASA am Standort 111.111.111.111 (VDSL).
Der ADSLer ist ca. 30 Minuten vorher dran,
Wie und wann die Zwangstrennung gemacht wird ist dir klar und wie du die Zeit wann diese gemacht wird beeinflussen kannst?als wenn dieser manuell getrennt wird.
Bei Automatischer Zwnagstrennung wird kein Stecker gezogen. Du bei Manuell aber vermutlich den Stecker irgendwo ziehst.Zudem hilft auch nur ein Neustart der ASA am Standort 111.111.111.111 (VDSL)
Fehlerhafte Konfig?Welche anderen Standorte hast du bei deinen Kunden welche auch mit VDSL des gleichen ISP Arbeitet wo auch das gleiche Modem und ASA in gleicher Konfiguration verwendest (ADSL <> VDSL)? Was ergibt ein Vergleich mit deren Konfiguration(en)?
Was sagt ein Wireshark auf der Verbindung zwischen Modem und ASA?
Gruß,
Peter
Hallo,
- Hast Du einmal an eine Zeitschaltuhr gedacht die eventuell nach der
Zwangstrennung am VDSL Standort die ASA neu startet, also nach der
Zwangstrennung das was Du zur Zeit manuell ausführst, automatisch
für Dich erledigt, ich meine dass ist zwar auch keine Lösung nur Du
musst eben nicht immer wieder "Hand anlegen".
Gruß
Dobby
- Hast Du einmal an eine Zeitschaltuhr gedacht die eventuell nach der
Zwangstrennung am VDSL Standort die ASA neu startet, also nach der
Zwangstrennung das was Du zur Zeit manuell ausführst, automatisch
für Dich erledigt, ich meine dass ist zwar auch keine Lösung nur Du
musst eben nicht immer wieder "Hand anlegen".
Gruß
Dobby
Hallo!
Mal ganz was anderes.
Ich hatte eine korrekte Konfiguration laufen (Allerdings Unitymedia - Kabel). Jedenfalls, bevor das Gebäude, was ich neu versorgt hatte, auf Last ging, d. h. den täglichen Betrieb aufnahm. Ab dann kam es immer zu Verbindungsabbrüchen, wobei nur ein Routerreset / Neustart half, ab dann ging die Anwahl problemlos und hielt Zeitraum x (mal länger, mal kürzer). Diagnostisch nix zu finden, alles durchgemessen (Provider). Ansonsten Konfig ähnlich wie bei dir, auch feste Adressen usw.
Lösung: Das ganze steht im Rack. Das Modem direkt beim Router. Das Modem hat wohl in den Router gestört. Als ich das an eine andere Stelle gesetzt hatte, waren die Probleme vorbei.
Muss zu deinem Problem nicht unbedingt passen, aber ich war zunächst auch ähnlich Ratlos wie du.
Gruß,
Andreas
Mal ganz was anderes.
Ich hatte eine korrekte Konfiguration laufen (Allerdings Unitymedia - Kabel). Jedenfalls, bevor das Gebäude, was ich neu versorgt hatte, auf Last ging, d. h. den täglichen Betrieb aufnahm. Ab dann kam es immer zu Verbindungsabbrüchen, wobei nur ein Routerreset / Neustart half, ab dann ging die Anwahl problemlos und hielt Zeitraum x (mal länger, mal kürzer). Diagnostisch nix zu finden, alles durchgemessen (Provider). Ansonsten Konfig ähnlich wie bei dir, auch feste Adressen usw.
Lösung: Das ganze steht im Rack. Das Modem direkt beim Router. Das Modem hat wohl in den Router gestört. Als ich das an eine andere Stelle gesetzt hatte, waren die Probleme vorbei.
Muss zu deinem Problem nicht unbedingt passen, aber ich war zunächst auch ähnlich Ratlos wie du.
Gruß,
Andreas
Hi
Nur mal so nebenbei das Zyxel VMG1312 ist kein Modem. Sondern ein Router mit Modem.
System Specifications:
VDSL Compliance
ITU-T G.993.1 VDSL1 compliant
ITU-T G.993.2 VDSL2, band plan 997, 998
Support VDSL profile: 8a/b/c/d, 12a/b, and 17a
Rate adaption
Dual-latency
Seamless Rate Adaption (SRA)
INP: up to 16 symbols
PTM mode
G.INP
PhyR configurable
ADSL Compliance
ITU-T G.992.1 (G.dmt) compliant
ITU-T G.992.2 (G.lite) compliant
ITU-T G.992.3 (ADSL2) compliant
ITU-T G.992.5 (ADSL2+) compliant
Reach-Extended ADSL (RE ADSL)
Seamless Rate Adaption (SRA)
Support VC-based and LLC-based multiplexing
WLAN
IEEE 802.11 b/g/n compliance
Frequency: 2.4 GHz
Data rate: 300 Mbps
WPA/WPA-PSK, WPA2/WPA2-PSK
WEP data encryption 64/128 bit
Wireless Protected Setup (WPS)
Multi SSID (up to 4) and hidden SSID support
USB
File sharing
3G backup support
Bridge/Router
PPPoE (RFC2516)
PPPoA (RFC2364)
DHCP client/server/relay
DNS proxy
Dynamic DNS
RIP I/RIP II supported
UPnP
Static/policy route
QoS classification route
Firewall/Security
PAP and CHAP support
MS-CHAPv1 and v2 support
Stateful Packet Inspection (SPI)
DoS Attack Prevention
Parental Control
QoS
Queuing and scheduling
Queue management
Management
Web GUI
Command Line Interpreter (CLI) via SSH or Telnet
Firmware upgrade via Web/FTP/TFTP
DSL forum TR-064, 069, 098,111
Configurable access control for remote management
Hardware Specifications
WAN:
One RJ-11 port (VMG1312-B10A) for VDSL/ADSL2+ over POTS
One RJ-45 port (VMG1312-B30A) for VDSL/ADSL2+ over ISDN
LAN: Four Fast Ethernet ports
WLAN: Two internal antennas
USB: One for USB2.0 host interface
WLAN/WPS button: One real button for WLAN on/off and WPS configuration
Reset/Restore button: One real button for restore factory default settings
Status LED indicator: Power, Ethernet, DSL, Internet, WLAN/WPS, USB
Physical Specifications
Item dimensions (W x D x H):186 x 121 x 39 mm (7.32” x 4.76” x 1.54”)
Item weight: 245 g (0.54 lb.)
Packing dimensions (W x D x H):300 x 195 x 50 mm (11.81” x 7.68” x 1.97”)
Packing weight: 540 g (1.19 lb.)
Environmental Specifications
Operating Environment
Temperature: 0°C to 40°C (32°F to 104°F)
Humidity: 20% to 95% RH (Non-condensing)
Storage Environment
Temperature: -30°C to 60°C (-22°F to 140°F)
Humidity: 20% to 95% RH (Non-condensing)
Certification
EMC: CE, FCC
Safety: CE
Die Konfiguration dieses geräts wäre eventuell auch intressant für die Lösung.
LG
Nur mal so nebenbei das Zyxel VMG1312 ist kein Modem. Sondern ein Router mit Modem.
System Specifications:
VDSL Compliance
ITU-T G.993.1 VDSL1 compliant
ITU-T G.993.2 VDSL2, band plan 997, 998
Support VDSL profile: 8a/b/c/d, 12a/b, and 17a
Rate adaption
Dual-latency
Seamless Rate Adaption (SRA)
INP: up to 16 symbols
PTM mode
G.INP
PhyR configurable
ADSL Compliance
ITU-T G.992.1 (G.dmt) compliant
ITU-T G.992.2 (G.lite) compliant
ITU-T G.992.3 (ADSL2) compliant
ITU-T G.992.5 (ADSL2+) compliant
Reach-Extended ADSL (RE ADSL)
Seamless Rate Adaption (SRA)
Support VC-based and LLC-based multiplexing
WLAN
IEEE 802.11 b/g/n compliance
Frequency: 2.4 GHz
Data rate: 300 Mbps
WPA/WPA-PSK, WPA2/WPA2-PSK
WEP data encryption 64/128 bit
Wireless Protected Setup (WPS)
Multi SSID (up to 4) and hidden SSID support
USB
File sharing
3G backup support
Bridge/Router
PPPoE (RFC2516)
PPPoA (RFC2364)
DHCP client/server/relay
DNS proxy
Dynamic DNS
RIP I/RIP II supported
UPnP
Static/policy route
QoS classification route
Firewall/Security
PAP and CHAP support
MS-CHAPv1 and v2 support
Stateful Packet Inspection (SPI)
DoS Attack Prevention
Parental Control
QoS
Queuing and scheduling
Queue management
Management
Web GUI
Command Line Interpreter (CLI) via SSH or Telnet
Firmware upgrade via Web/FTP/TFTP
DSL forum TR-064, 069, 098,111
Configurable access control for remote management
Hardware Specifications
WAN:
One RJ-11 port (VMG1312-B10A) for VDSL/ADSL2+ over POTS
One RJ-45 port (VMG1312-B30A) for VDSL/ADSL2+ over ISDN
LAN: Four Fast Ethernet ports
WLAN: Two internal antennas
USB: One for USB2.0 host interface
WLAN/WPS button: One real button for WLAN on/off and WPS configuration
Reset/Restore button: One real button for restore factory default settings
Status LED indicator: Power, Ethernet, DSL, Internet, WLAN/WPS, USB
Physical Specifications
Item dimensions (W x D x H):186 x 121 x 39 mm (7.32” x 4.76” x 1.54”)
Item weight: 245 g (0.54 lb.)
Packing dimensions (W x D x H):300 x 195 x 50 mm (11.81” x 7.68” x 1.97”)
Packing weight: 540 g (1.19 lb.)
Environmental Specifications
Operating Environment
Temperature: 0°C to 40°C (32°F to 104°F)
Humidity: 20% to 95% RH (Non-condensing)
Storage Environment
Temperature: -30°C to 60°C (-22°F to 140°F)
Humidity: 20% to 95% RH (Non-condensing)
Certification
EMC: CE, FCC
Safety: CE
Die Konfiguration dieses geräts wäre eventuell auch intressant für die Lösung.
LG
Sorry, dass ich den alten Thread nochmal aufgreife, aber gabs hier noch irgendwelche Ergebnisse oder Erkenntnisse? Wir haben ähnliche Phänomene. Haben hier knapp 50 ASA 5505 die hier zentral auf eine 5520 terminieren. Großteil über Telekom ADSL 16000. Konfig außer den Standortunterschiedlichen Parametern absolut identisch. Die meisten Standort laufen absolut problemlos.
Bei einigen wenigen aber genau die gleichen Probleme wie hier genannt. Immer nach genau 24 h fliegt an diesen Problemkindern der VPN-Tunnel weg und kommt nicht wieder hoch. Dann booten wir die externe ASA über die öffentliche IP-Adresse und der Tunnel kommt wieder. Wir haben schon zig Versuche gemacht, ohne Lösung...
Wie gesagt wäre sehr interessiert, ob hier noch was rausgekommen ist. Danke!
Bei einigen wenigen aber genau die gleichen Probleme wie hier genannt. Immer nach genau 24 h fliegt an diesen Problemkindern der VPN-Tunnel weg und kommt nicht wieder hoch. Dann booten wir die externe ASA über die öffentliche IP-Adresse und der Tunnel kommt wieder. Wir haben schon zig Versuche gemacht, ohne Lösung...
Wie gesagt wäre sehr interessiert, ob hier noch was rausgekommen ist. Danke!
Hi
Wenn es vorort an den nicht funktionierenden standorten einen Server oder PC gibt den du benutzen kannst würde ich mit https://www.pingplotter.com/ einen Ping über den VPN Tunnel laufen lassen einen zum Gateway deiner Internetverbindung und schauen was für Erkenntnisse du gewinnst.
Wie schauen den die Einstellungen der VPN tunnels aus ? Sollte der bei einer Trennung automatisch neu verbinden ? Ist DPD ach auf beiden seiten Aktiv ?
LG
Wenn es vorort an den nicht funktionierenden standorten einen Server oder PC gibt den du benutzen kannst würde ich mit https://www.pingplotter.com/ einen Ping über den VPN Tunnel laufen lassen einen zum Gateway deiner Internetverbindung und schauen was für Erkenntnisse du gewinnst.
Wie schauen den die Einstellungen der VPN tunnels aus ? Sollte der bei einer Trennung automatisch neu verbinden ? Ist DPD ach auf beiden seiten Aktiv ?
LG