Hallo liebe Supporter!
Mich plagen seit einiger Zeit, Paketfragmentierung bei IPSec VPN-Tunnels.
Wir haben in unserem Unternehmen als zentrales Gateway:
2 x 8011 im VRRP Verbund an einer SFV 10 MBit (MTU 1500)
An den Gegenstellen:
jeweils 1611+
und 1711 VPN (insgesamt 23 Gegenstellen) mit jeweils 2 MBit SHDSL Leitungen
Von den Gegenstellen besitzen die Hälfte QSC SHDSL Leitungen und die andere gemischt T-COM, Claranet und No Name Provider.
Entgegen der Aussage der Provider (MTU=1500) sind viele der Leitungen mit MTU Sizes von 1492 synchronisiert. Und daher geht ein:
ping -f -l 1464 IP-Adresse
noch durch aber mit 1472 nicht mehr.
So nun aber zu meinen Problemen:
1. vorweg eine Frage nebenbei: lässt sich im Lancom die Concurrent Connections herausfinden?
2. Wie kann es sein dass bei einer Änderung der MTU Size auf der Gegenstelle der Lancom den VPN Tunnel aufbaut aber minutenlang (sogar bis zu einer halben h) keine Pakete, weder ping noch andere Protokolle durchgehen.
3. Wie kann man eine Paketfragementierung verhindern?
Gibt es eine Schalter im Lancom um fragmentierte Pakete auszuschliessen?
Vermutung liegt nahe dass durch falsche MTU Werte die Pakete so durcheinander gewürfelt werden dass selbst IPSec Tunnels instabil werden und somit desöfteren zusammenbrechen. Und dann tritt das seltsame Phänomen auf dass der Tunnel erst nach Minuten wieder aufgebaut wird anstelle sofort.
Also das sind gleich 3 Wünsche auf ein Mal aber sehr gravierende Probleme und möglicherweise kann mir hier jemand weiterhelfen.
Vielen Dank!
Grüße
Capricorn72
instabile VPN Tunnels: MTU und Paketfragmentierung !!!!!
Moderator: Lancom-Systems Moderatoren
-
capricorn72
- Beiträge: 38
- Registriert: 18 Jul 2005, 08:33
instabile VPN Tunnels: MTU und Paketfragmentierung !!!!!
Es gibt immer eine Lösung, man muss sie nur finden!
Hi capricorn72
Du mußt aber bei "gemischten" MTUs (d.h. auf einer Seite 1500 und auf der anderen 1492) in den LANCOMs die MTU auf die kleinste der beteiligten einstellen (unter Kommunikation -> Protokolle -> MTU-Liste). Wenn du es dir einfach machen willst stellst du überall für die Internetverbindung die MTU auf 1492 ein. Du kannst die MTU aber auch für die VPN-Verbindungen einzeln einstellen - hier gilt VPN-MTU = Internet-MTU - 100 (hier ist natürlich auch die jeweils kleinste Internet-MTU einzusetzen)
Gruß
Backslash
eine Anmerkung vorweg: Das ist hier mitnichten ein Support-Forum - es ist ein User-Forum...Hallo liebe Supporter!
Sobald PPPoE gemacht wird, ist die MTU maximal 1492. Wenn der Provider das korrekt signalisiert (MRU in der PPP-Verhandlung) stellt sich das LANCOM darauf ein.Entgegen der Aussage der Provider (MTU=1500) sind viele der Leitungen mit MTU Sizes von 1492 synchronisiert
was meinst du damit?1. vorweg eine Frage nebenbei: lässt sich im Lancom die Concurrent Connections herausfinden?
hab ich noch nie erlebt.2. Wie kann es sein dass bei einer Änderung der MTU Size auf der Gegenstelle der Lancom den VPN Tunnel aufbaut aber minutenlang (sogar bis zu einer halben h) keine Pakete, weder ping noch andere Protokolle durchgehen.
wenn die MTU in der PPP-Verhandlung korrekt ausgehandelt wird, dann verhindert das LANCOM selbst eine Fragmentierung - zumindest bei TCP-Verbindungen (hier greift es in der TCP-Verbindungsaufbau ein und erzwingt eine passende MSS). Bei anderen Protokollen fragmentiert das LANCOM oder schickt eine ICMP-Fehlermeldung (fragmentation needed, but DF bit set) zurück.3. Wie kann man eine Paketfragementierung verhindern?
Du kannst unter Firewall/QoS -> Allgemein einstellen, was das LANCOM mit fragmenten machen soll. Default ist "Re-Assemblieren".Gibt es eine Schalter im Lancom um fragmentierte Pakete auszuschliessen?
eher unwahrscheinlich...Vermutung liegt nahe dass durch falsche MTU Werte die Pakete so durcheinander gewürfelt werden dass selbst IPSec Tunnels instabil werden und somit desöfteren zusammenbrechen
Du mußt aber bei "gemischten" MTUs (d.h. auf einer Seite 1500 und auf der anderen 1492) in den LANCOMs die MTU auf die kleinste der beteiligten einstellen (unter Kommunikation -> Protokolle -> MTU-Liste). Wenn du es dir einfach machen willst stellst du überall für die Internetverbindung die MTU auf 1492 ein. Du kannst die MTU aber auch für die VPN-Verbindungen einzeln einstellen - hier gilt VPN-MTU = Internet-MTU - 100 (hier ist natürlich auch die jeweils kleinste Internet-MTU einzusetzen)
das liegt daran, daß die Gegenseite einem einseitigen Abbruch nicht mitbekommt und weiterhin der Meinung ist, daß der Tunnel noch stehen würde. Hier muß erst die Lifetime der IPSec-SAs ablaufen, bevor ein neuer Tunnel aufgebaut werden kann. Das kannst du über ein ICMP- oder DPD-Polling beschleunigen.Und dann tritt das seltsame Phänomen auf dass der Tunnel erst nach Minuten wieder aufgebaut wird anstelle sofort.
Gruß
Backslash
-
capricorn72
- Beiträge: 38
- Registriert: 18 Jul 2005, 08:33
>>> Hallo Backslash!
Zitat: ‹ Select ›
Hallo liebe Supporter!
eine Anmerkung vorweg: Das ist hier mitnichten ein Support-Forum - es ist ein User-Forum...
>>> ok sorry daher erst mal Vielen Dank für Deine schnelle Antwort.
Zitat: ‹ Select ›
Entgegen der Aussage der Provider (MTU=1500) sind viele der Leitungen mit MTU Sizes von 1492 synchronisiert
Sobald PPPoE gemacht wird, ist die MTU maximal 1492. Wenn der Provider das korrekt signalisiert (MRU in der PPP-Verhandlung) stellt sich das LANCOM darauf ein.
>>> Das Lancom kann sich nicht darauf einstellen da hier keine Gegenstelle mit PPPoE arbeitet. Im Text steht explizit SHDSL, das sind Plain Ethernet Verbindungen. Daher nimmt der Lancom immer eine 1500.
Zitat: ‹ Select ›
1. vorweg eine Frage nebenbei: lässt sich im Lancom die Concurrent Connections herausfinden?
was meinst du damit?
>>> Concurrent Connections sind gemeint wie viele TCP Verbindungen parallel im Augenblick aufgebaut sind. Diese können über das NAT nach Extern ins Internet gehen welche lt. Lancom Tabelle nur 4096 betragen können und ohne NAT abhängig vom Speicher sind. Und genau das möchte ich herausfinden.
Zitat: ‹ Select ›
2. Wie kann es sein dass bei einer Änderung der MTU Size auf der Gegenstelle der Lancom den VPN Tunnel aufbaut aber minutenlang (sogar bis zu einer halben h) keine Pakete, weder ping noch andere Protokolle durchgehen.
hab ich noch nie erlebt.
>>> weil der Lancom ja auch keine Automatische Aushandlung der MTU kann und auch lt. RFC im IPSec nicht implementiert ist. Daher ist dies wohl doch ein Fragmentierungsproblem.
Zitat: ‹ Select ›
3. Wie kann man eine Paketfragementierung verhindern?
wenn die MTU in der PPP-Verhandlung korrekt ausgehandelt wird, dann verhindert das LANCOM selbst eine Fragmentierung - zumindest bei TCP-Verbindungen (hier greift es in der TCP-Verbindungsaufbau ein und erzwingt eine passende MSS). Bei anderen Protokollen fragmentiert das LANCOM oder schickt eine ICMP-Fehlermeldung (fragmentation needed, but DF bit set) zurück.
>>> ist bestimmt richtig aber da hier immer mit 1500 ausgehandelt wird in unserem Fall, arbeitet der Lancom automatisch nur mit 1400 im IPSec Tunnel. WAN_MTU - 100 = IPSec MTU lautet wohl die Formel im Lancom.
Zitat: ‹ Select ›
Gibt es eine Schalter im Lancom um fragmentierte Pakete auszuschliessen?
Du kannst unter Firewall/QoS -> Allgemein einstellen, was das LANCOM mit fragmenten machen soll. Default ist "Re-Assemblieren".
>>> würde der Schalter "Filter" anstelle "Re-Assemblieren" eine Besserung bringen?
Zitat: ‹ Select ›
Vermutung liegt nahe dass durch falsche MTU Werte die Pakete so durcheinander gewürfelt werden dass selbst IPSec Tunnels instabil werden und somit desöfteren zusammenbrechen
eher unwahrscheinlich...
>>> was kann dann dazu führen dass IPSec Tunnel wenn sie im selben Provider Backbone liegen abgebaut werden?
Wenn man davon ausgeht dass der Provider keine internen Probleme hat!
Du mußt aber bei "gemischten" MTUs (d.h. auf einer Seite 1500 und auf der anderen 1492) in den LANCOMs die MTU auf die kleinste der beteiligten einstellen (unter Kommunikation -> Protokolle -> MTU-Liste). Wenn du es dir einfach machen willst stellst du überall für die Internetverbindung die MTU auf 1492 ein. Du kannst die MTU aber auch für die VPN-Verbindungen einzeln einstellen - hier gilt VPN-MTU = Internet-MTU - 100 (hier ist natürlich auch die jeweils kleinste Internet-MTU einzusetzen)
>>> würde das bedeuten dass an der Zentrale keine 1500 eingestellt werden sollte sondern 1492 wie an den Aussenstellen?
Und wenn nur eine dieser Aussenstellen auf 1464 steht, müssen dann alle anderen ebenfalls damit arbeiten incl. Zentrale?
Zitat: ‹ Select ›
Und dann tritt das seltsame Phänomen auf dass der Tunnel erst nach Minuten wieder aufgebaut wird anstelle sofort.
das liegt daran, daß die Gegenseite einem einseitigen Abbruch nicht mitbekommt und weiterhin der Meinung ist, daß der Tunnel noch stehen würde. Hier muß erst die Lifetime der IPSec-SAs ablaufen, bevor ein neuer Tunnel aufgebaut werden kann. Das kannst du über ein ICMP- oder DPD-Polling beschleunigen.
>>> wäre hier ein ICMP- oder DPD-Polling von der Zentrale an die Gegenstellen und auch von den Gegenstellen zur Zentrale empfehlenswert damit sobald einer einen Fehler hat dann auch beide sofort trennen und eine Neuverhandlung beginnen?
Gruß
Capricorn72
Zitat: ‹ Select ›
Hallo liebe Supporter!
eine Anmerkung vorweg: Das ist hier mitnichten ein Support-Forum - es ist ein User-Forum...
>>> ok sorry daher erst mal Vielen Dank für Deine schnelle Antwort.
Zitat: ‹ Select ›
Entgegen der Aussage der Provider (MTU=1500) sind viele der Leitungen mit MTU Sizes von 1492 synchronisiert
Sobald PPPoE gemacht wird, ist die MTU maximal 1492. Wenn der Provider das korrekt signalisiert (MRU in der PPP-Verhandlung) stellt sich das LANCOM darauf ein.
>>> Das Lancom kann sich nicht darauf einstellen da hier keine Gegenstelle mit PPPoE arbeitet. Im Text steht explizit SHDSL, das sind Plain Ethernet Verbindungen. Daher nimmt der Lancom immer eine 1500.
Zitat: ‹ Select ›
1. vorweg eine Frage nebenbei: lässt sich im Lancom die Concurrent Connections herausfinden?
was meinst du damit?
>>> Concurrent Connections sind gemeint wie viele TCP Verbindungen parallel im Augenblick aufgebaut sind. Diese können über das NAT nach Extern ins Internet gehen welche lt. Lancom Tabelle nur 4096 betragen können und ohne NAT abhängig vom Speicher sind. Und genau das möchte ich herausfinden.
Zitat: ‹ Select ›
2. Wie kann es sein dass bei einer Änderung der MTU Size auf der Gegenstelle der Lancom den VPN Tunnel aufbaut aber minutenlang (sogar bis zu einer halben h) keine Pakete, weder ping noch andere Protokolle durchgehen.
hab ich noch nie erlebt.
>>> weil der Lancom ja auch keine Automatische Aushandlung der MTU kann und auch lt. RFC im IPSec nicht implementiert ist. Daher ist dies wohl doch ein Fragmentierungsproblem.
Zitat: ‹ Select ›
3. Wie kann man eine Paketfragementierung verhindern?
wenn die MTU in der PPP-Verhandlung korrekt ausgehandelt wird, dann verhindert das LANCOM selbst eine Fragmentierung - zumindest bei TCP-Verbindungen (hier greift es in der TCP-Verbindungsaufbau ein und erzwingt eine passende MSS). Bei anderen Protokollen fragmentiert das LANCOM oder schickt eine ICMP-Fehlermeldung (fragmentation needed, but DF bit set) zurück.
>>> ist bestimmt richtig aber da hier immer mit 1500 ausgehandelt wird in unserem Fall, arbeitet der Lancom automatisch nur mit 1400 im IPSec Tunnel. WAN_MTU - 100 = IPSec MTU lautet wohl die Formel im Lancom.
Zitat: ‹ Select ›
Gibt es eine Schalter im Lancom um fragmentierte Pakete auszuschliessen?
Du kannst unter Firewall/QoS -> Allgemein einstellen, was das LANCOM mit fragmenten machen soll. Default ist "Re-Assemblieren".
>>> würde der Schalter "Filter" anstelle "Re-Assemblieren" eine Besserung bringen?
Zitat: ‹ Select ›
Vermutung liegt nahe dass durch falsche MTU Werte die Pakete so durcheinander gewürfelt werden dass selbst IPSec Tunnels instabil werden und somit desöfteren zusammenbrechen
eher unwahrscheinlich...
>>> was kann dann dazu führen dass IPSec Tunnel wenn sie im selben Provider Backbone liegen abgebaut werden?
Wenn man davon ausgeht dass der Provider keine internen Probleme hat!
Du mußt aber bei "gemischten" MTUs (d.h. auf einer Seite 1500 und auf der anderen 1492) in den LANCOMs die MTU auf die kleinste der beteiligten einstellen (unter Kommunikation -> Protokolle -> MTU-Liste). Wenn du es dir einfach machen willst stellst du überall für die Internetverbindung die MTU auf 1492 ein. Du kannst die MTU aber auch für die VPN-Verbindungen einzeln einstellen - hier gilt VPN-MTU = Internet-MTU - 100 (hier ist natürlich auch die jeweils kleinste Internet-MTU einzusetzen)
>>> würde das bedeuten dass an der Zentrale keine 1500 eingestellt werden sollte sondern 1492 wie an den Aussenstellen?
Und wenn nur eine dieser Aussenstellen auf 1464 steht, müssen dann alle anderen ebenfalls damit arbeiten incl. Zentrale?
Zitat: ‹ Select ›
Und dann tritt das seltsame Phänomen auf dass der Tunnel erst nach Minuten wieder aufgebaut wird anstelle sofort.
das liegt daran, daß die Gegenseite einem einseitigen Abbruch nicht mitbekommt und weiterhin der Meinung ist, daß der Tunnel noch stehen würde. Hier muß erst die Lifetime der IPSec-SAs ablaufen, bevor ein neuer Tunnel aufgebaut werden kann. Das kannst du über ein ICMP- oder DPD-Polling beschleunigen.
>>> wäre hier ein ICMP- oder DPD-Polling von der Zentrale an die Gegenstellen und auch von den Gegenstellen zur Zentrale empfehlenswert damit sobald einer einen Fehler hat dann auch beide sofort trennen und eine Neuverhandlung beginnen?
Gruß
Capricorn72
Es gibt immer eine Lösung, man muss sie nur finden!
Hi capricorn72
das Forum hat eine so schöne Zitatfunktion - die macht das Ganze deutlich übersichtlicher...
Gruß
Backslash
das Forum hat eine so schöne Zitatfunktion - die macht das Ganze deutlich übersichtlicher...
im Telnet (oder der Expertenkonfiguration der WEBconfig) findest du die Tabelle unter /Status/IP-Router/Connection-ListConcurrent Connections sind gemeint wie viele TCP Verbindungen parallel im Augenblick aufgebaut sind. Diese können über das NAT nach Extern ins Internet gehen welche lt. Lancom Tabelle nur 4096 betragen können und ohne NAT abhängig vom Speicher sind. Und genau das möchte ich herausfinden.
wie gesagt, daß bei einem aufgebauten Tunnel keine Pakete (also selbst pings) minutenlang nicht durchgehen habe ich noch nie erlebt (außer, wenn da irgendwo noch eine Firewall oder ein Router zwischen war, die mit IPSec nicht umgehen konnten)weil der Lancom ja auch keine Automatische Aushandlung der MTU kann und auch lt. RFC im IPSec nicht implementiert ist. Daher ist dies wohl doch ein Fragmentierungsproblem.
korrekt - die Formel hatte ich in meinem Post ebenfalls genannt.ist bestimmt richtig aber da hier immer mit 1500 ausgehandelt wird in unserem Fall, arbeitet der Lancom automatisch nur mit 1400 im IPSec Tunnel. WAN_MTU - 100 = IPSec MTU lautet wohl die Formel im Lancom.
Re-Assemblieren ist eigentlich die beste Einstellung - wenn du filtern sagst, dann bekommst du u.U. Probleme, wenn du mit Anwendungen arbeitest, die von sich aus schon fragmentieren. Ein Beispiel hierfür wäre ein VPN-Client, der sein Zertifikat an seinen Server verschickt.würde der Schalter "Filter" anstelle "Re-Assemblieren" eine Besserung bringen?
ggf. ist es ja doch der Provider...was kann dann dazu führen dass IPSec Tunnel wenn sie im selben Provider Backbone liegen abgebaut werden?
Wenn man davon ausgeht dass der Provider keine internen Probleme hat!
du hast es erfasst...würde das bedeuten dass an der Zentrale keine 1500 eingestellt werden sollte sondern 1492 wie an den Aussenstellen?
Und wenn nur eine dieser Aussenstellen auf 1464 steht, müssen dann alle anderen ebenfalls damit arbeiten incl. Zentrale?
Es ist immer sinnvoll, das Polling in beide Reichtungen zu machen...wäre hier ein ICMP- oder DPD-Polling von der Zentrale an die Gegenstellen und auch von den Gegenstellen zur Zentrale empfehlenswert damit sobald einer einen Fehler hat dann auch beide sofort trennen und eine Neuverhandlung beginnen?
Gruß
Backslash
Hi,
Ciao
LoUiS
Deine Aussage ist aber nicht generell fuer SHDSL gueltig! Mein eigener QSC SHDSL Zugang hat derzeit eine (automatisch ausgehandelte) MTU von 1492!>>> Das Lancom kann sich nicht darauf einstellen da hier keine Gegenstelle mit PPPoE arbeitet. Im Text steht explizit SHDSL, das sind Plain Ethernet Verbindungen. Daher nimmt der Lancom immer eine 1500.
Ciao
LoUiS
Dr.House hat geschrieben:Dr. House: Du bist geheilt. Steh auf und wandle.
Patient: Sind Sie geisteskrank?
Dr. House: In der Bibel sagen die Leute schlicht "Ja, Herr" und verfallen dann ins Lobpreisen.
-
capricorn72
- Beiträge: 38
- Registriert: 18 Jul 2005, 08:33
Hallo LoUiS!
Vielen Dank für Deine Antwort.
An Deinem Anschluss wird der Provider auf dem internen Provider-Router Interface mit Sicherheit dann auch 1492 eingestellt haben. Das ist dann auch richtig so.
Stelle Dir aber vor, dass der Provider QSC auch anders kann.
Cisco Router 1841 auf dem externem Interface 1492 und auf dem internen Interface 1500 eingestellt.
Dann muss der Lancom zwingend auf 1492 eingestellt werden, da sonst Fragmentierung los geht.
Und das ist wahrscheinlich mein Problem, dass über Strecken mit dieser Konfiguration ein stabiler VPN Tunnel nur dann zustande kommt, wenn der Lancom manuell die MTU angepasst bekommt.
Desweiteren habe ich die nachfolgende config pro VPN Tunnel:
Ike:
Main Mode
AES 256
SHA1
DH Group 2
SA Lifetime: 86400
IPSec:
ESP
AES 256
SHA1
SA Lifetime 3600
PFS Group 2
no compression
Keep Alive: 9999
DPD-Polling Eintrag: auf interne VRRP IP-Adresse der 8011er
Ausserdem stehen die Netzbeziehungen komplett auf manuell.
Daher existieren für jeden VPN Tunnel auch 2 VPN-Regeln in der Firewall.
Je eine "In" und eine "Out" Regel da Netze von klein nach groß geroutet werden. D.h. von 24 Bit nach 8 Bit Netz und umgekehrt.
Nun habe ich aber mal begonnen anstelle jeden Tunnel manuell anzulegen, diesen mit dem 1-Click VPN Assistenten im Lanconfig anzulegen. Drag and Drop: Aussenstelle über die Zentrale.
Danach wird automatisch ein Dynamic VPN angelegt, welches nur noch der Aussenstelle erlaubt sich automatisch mit der Zentrale zu verbinden.
D.h. die Zentrale hat dann kein DPD mehr aktiviert.
Das könnte die Lösung sein wenn ein VPN Tunnel abbricht.
Denn die Aussenstelle würde diesen sofort wieder aufbauen. Und das schöne dabei ist dass mit dem Assistenten die Tunnelstabilität wohl zugenommen hat aufgrund anderen Proposals:
AES 128
MD5
Meine Vermutung liegt daher auch in Richtung der Proposals dass diese nicht über jede Strecke sauber funktionieren.
Das würde dann erklären warum mit AES 256 minutenlang kein Traffic durch den Tunnel geht, mit AES 128 und dem 1-Click Assistenten aber sofort.
Das ist nur eine Vermutung und ich lasse mich gerne eines Besseren belehren. Hauptsache der Sache kann man auf den Grund gehen. Möglicherweise sind beide verantwortlich, MTU und Proposal.
Grüße
Capricorn72
Vielen Dank für Deine Antwort.
An Deinem Anschluss wird der Provider auf dem internen Provider-Router Interface mit Sicherheit dann auch 1492 eingestellt haben. Das ist dann auch richtig so.
Stelle Dir aber vor, dass der Provider QSC auch anders kann.
Cisco Router 1841 auf dem externem Interface 1492 und auf dem internen Interface 1500 eingestellt.
Dann muss der Lancom zwingend auf 1492 eingestellt werden, da sonst Fragmentierung los geht.
Und das ist wahrscheinlich mein Problem, dass über Strecken mit dieser Konfiguration ein stabiler VPN Tunnel nur dann zustande kommt, wenn der Lancom manuell die MTU angepasst bekommt.
Desweiteren habe ich die nachfolgende config pro VPN Tunnel:
Ike:
Main Mode
AES 256
SHA1
DH Group 2
SA Lifetime: 86400
IPSec:
ESP
AES 256
SHA1
SA Lifetime 3600
PFS Group 2
no compression
Keep Alive: 9999
DPD-Polling Eintrag: auf interne VRRP IP-Adresse der 8011er
Ausserdem stehen die Netzbeziehungen komplett auf manuell.
Daher existieren für jeden VPN Tunnel auch 2 VPN-Regeln in der Firewall.
Je eine "In" und eine "Out" Regel da Netze von klein nach groß geroutet werden. D.h. von 24 Bit nach 8 Bit Netz und umgekehrt.
Nun habe ich aber mal begonnen anstelle jeden Tunnel manuell anzulegen, diesen mit dem 1-Click VPN Assistenten im Lanconfig anzulegen. Drag and Drop: Aussenstelle über die Zentrale.
Danach wird automatisch ein Dynamic VPN angelegt, welches nur noch der Aussenstelle erlaubt sich automatisch mit der Zentrale zu verbinden.
D.h. die Zentrale hat dann kein DPD mehr aktiviert.
Das könnte die Lösung sein wenn ein VPN Tunnel abbricht.
Denn die Aussenstelle würde diesen sofort wieder aufbauen. Und das schöne dabei ist dass mit dem Assistenten die Tunnelstabilität wohl zugenommen hat aufgrund anderen Proposals:
AES 128
MD5
Meine Vermutung liegt daher auch in Richtung der Proposals dass diese nicht über jede Strecke sauber funktionieren.
Das würde dann erklären warum mit AES 256 minutenlang kein Traffic durch den Tunnel geht, mit AES 128 und dem 1-Click Assistenten aber sofort.
Das ist nur eine Vermutung und ich lasse mich gerne eines Besseren belehren. Hauptsache der Sache kann man auf den Grund gehen. Möglicherweise sind beide verantwortlich, MTU und Proposal.
Grüße
Capricorn72
Es gibt immer eine Lösung, man muss sie nur finden!