PPTP-Tunnel bricht weg
Hallo an das Forum,
ich habe ein Problem mit einem VPN-Tunnel zu einem Datenbank-Hoster.
Die Situation ist folgende: Wir bekommen in der Problemfiliale das Internet incl. Telefon von einem lokalen Anbieter auf eine "Genexis-Box". Da wir insgesamt fünf Filialen (vier mal Telekom Digitalisierungsbox Premium in den remoten Filialen) vernetzen, die "Genexis-Box" aber keine VPN-Tunnel aufbauen kann, wurde eine Portweiterleitung für VPN auf einen Bintec R3502-Router dahinter eingerichtet. Dieser Router baut insgesamt vierTunnel per IPSec in die Filialen und einen PPTP-Tunnel zu einem externen Datenbank-Hoster auf. Dieser Tunnel bricht in unregelmäßigen Abständen zusammen und damit stürzt die angebundene Software ab, oftmals unter Datenverlust.
Wir haben auf einem Testrechner in der Problemfiliale insgesamt vier Dauer-Pings auf unterschiedliche Ziele laufen:
- externe Adresse t-online
- Datenbank-Anbieter
- interner Bintec-Router
- externe Webadresse
Wir habe das Phänomen, dass nur der PPTP-Tunnel wegbricht:
Den Bintec-Router haben wir schon ausgetauscht - ohne Erfolg.
Hat jemand eine Idee, was hier passiert? Kann mir jemand ein Tool zum Monitoring und Fehlersuche des Tunnels empfehlen?
Vielen Dank schon mal,
Atti
ich habe ein Problem mit einem VPN-Tunnel zu einem Datenbank-Hoster.
Die Situation ist folgende: Wir bekommen in der Problemfiliale das Internet incl. Telefon von einem lokalen Anbieter auf eine "Genexis-Box". Da wir insgesamt fünf Filialen (vier mal Telekom Digitalisierungsbox Premium in den remoten Filialen) vernetzen, die "Genexis-Box" aber keine VPN-Tunnel aufbauen kann, wurde eine Portweiterleitung für VPN auf einen Bintec R3502-Router dahinter eingerichtet. Dieser Router baut insgesamt vierTunnel per IPSec in die Filialen und einen PPTP-Tunnel zu einem externen Datenbank-Hoster auf. Dieser Tunnel bricht in unregelmäßigen Abständen zusammen und damit stürzt die angebundene Software ab, oftmals unter Datenverlust.
Wir haben auf einem Testrechner in der Problemfiliale insgesamt vier Dauer-Pings auf unterschiedliche Ziele laufen:
- externe Adresse t-online
- Datenbank-Anbieter
- interner Bintec-Router
- externe Webadresse
Wir habe das Phänomen, dass nur der PPTP-Tunnel wegbricht:
Den Bintec-Router haben wir schon ausgetauscht - ohne Erfolg.
Hat jemand eine Idee, was hier passiert? Kann mir jemand ein Tool zum Monitoring und Fehlersuche des Tunnels empfehlen?
Vielen Dank schon mal,
Atti
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 653056
Url: https://administrator.de/contentid/653056
Ausgedruckt am: 19.11.2024 um 03:11 Uhr
32 Kommentare
Neuester Kommentar
Zwei Fragen noch:
- Hat die "Problemfiliale" einen DS-Lite Anschluss oder ist das ein normaler mit öffentlicher v4 IP ?
- Der PPTP Tunnel wird vom zentralen Standort zum Datenbank Anbieter gemacht, sprich Traffic aus der "Problemfiliale" geht also zuerst über den IPsec Tunnel zur Zentrale und wird dann dort in den PPTP Tunnel zum Ziel geroutet, richtig ?!
OK, dann kann man ja sicher den Link via Zentrale ausschliessen und auch die IPsec Tunnel denn die laufen ja, wie man sieht, absolut stabil. Dann ist es nur rein eine Sache zw. Filialrouter und Datenbank bzw. PPTP.
Die Fragen die jetzt daraus resultieren sind:
Am vielversprechensten ist der 3te Punkt. Billige Boxen können meist nur einen VPN Passthrough Link bedienen. Es ist möglich das bei aktivem IPsec Tunnel der PPTP Tunnel gekappt wird und erst wenn der per Idletimer deaktiviert ist der PPTP aktiv wird und das in stetigem Wechsel. Dann wäre aber ein Muster erkennbar, denn der Peer Idle Timer ist eine fixe Größe.
Die andere Sache wäre dann Punkt 1 was auf Routing Probleme zw. Filialprovider und Dienstleister Provider schliessen lässt. Das bekommt man aber raus indem man mal einen Dauerping von der Filiale auf den Dienstleister IP Tunnelendpunkt macht (sofern das geht). Fällt mit dem Tunnel auch der Ping aus könnte es das sein. Wenn mit Tunnelausfall der Ping weiterrennt kann man Routing Probleme ausschliessen.
In die Richtungen solltest du mal suchen...
Die Fragen die jetzt daraus resultieren sind:
- Liegt es an der Erreichbarkeit der Endpoint Adressen an sich also öffentliche Filialrouter IP und Datenbank IP wo der Tunnel endet ?
- Liegt es am PPTP Tunnel selber und wenn ja wo passieren die Abbrüche auf Fialialseite oder DB Seite ? (Hier wären Logs von BEIDEN Seiten hilfreich) Wobei man ja sagen kann wenn aus allen anderen Filialen und der Zentrale gleichzeitig ein Ping störungsfrei rennt kann man den Dienstleister sehr wahrscheinlich ausschliessen.
- Bleibt noch das Port Forwarding auf der Genesis Box zum Bintec, UDP 500, UDP 4500, ESP (50) für IPsec und TCP 1723 und GRE (47) für PPTP. Ist das unvollständig oder fehlerhaft oder funktioniert nicht richtig ? Die G Box muss ja zwingend dann Port Forwarding für beide VPN Protokolle machen.
Am vielversprechensten ist der 3te Punkt. Billige Boxen können meist nur einen VPN Passthrough Link bedienen. Es ist möglich das bei aktivem IPsec Tunnel der PPTP Tunnel gekappt wird und erst wenn der per Idletimer deaktiviert ist der PPTP aktiv wird und das in stetigem Wechsel. Dann wäre aber ein Muster erkennbar, denn der Peer Idle Timer ist eine fixe Größe.
Die andere Sache wäre dann Punkt 1 was auf Routing Probleme zw. Filialprovider und Dienstleister Provider schliessen lässt. Das bekommt man aber raus indem man mal einen Dauerping von der Filiale auf den Dienstleister IP Tunnelendpunkt macht (sofern das geht). Fällt mit dem Tunnel auch der Ping aus könnte es das sein. Wenn mit Tunnelausfall der Ping weiterrennt kann man Routing Probleme ausschliessen.
In die Richtungen solltest du mal suchen...
Außer "GRE (47)" ist eigentlich Alles eingerichtet:
Das ist aber fatal, denn genau das nutzt PPTP für die Wirkdaten und ist der Knackpunkt ! Es ist vergleichbar mit ESP bei IPsec. Wieso ist das vergessen worden ? Oder kennt der Router das nicht (müsste unter "Protocol" auftauchen, denn wie ESP ist GRE ein eigenständiges IP Protokoll mit der Nr. 47) ?"AH" kannst du übrigens besser komplett entfernen (Haken weg). Das ist nicht NAT fähig und wird deshalb nirgendwo in dem Umfeld verwendet !
Pingst du parallel auch mal die Dienstleister Tunnel Endpoint IP ??
Das wäre ja mal spannend zu wissen ob der auch weg ist wenn der Tunnelping scheitert. Dann wüsste man wenigstens obs ne reine IP Problemtaik ist oder ne Tunnelproblematik.
Wäre auch mal spannend wenn das beides parallel auch in einer der anderen Filialen gemacht wird.
Dann hätte man Gewissheit.
Das wäre ja mal spannend zu wissen ob der auch weg ist wenn der Tunnelping scheitert. Dann wüsste man wenigstens obs ne reine IP Problemtaik ist oder ne Tunnelproblematik.
Wäre auch mal spannend wenn das beides parallel auch in einer der anderen Filialen gemacht wird.
Dann hätte man Gewissheit.
den Tunnel selber anpingen - wie soll das gehen?
Das hast du vermutlich etwas missverstanden.Gemeint war die öffentliche Tunnelendpoint IP anzupingen und parallel einen Ping über den Tunnel also innerhalb der getunnelten IP Netze.
So hast du mit den beiden Pings einen Überblick ob es ein Routing Problem im öffentlichen Internet ist der den Tunnel per se zusamenbrechen lässt oder eben ein Problem des IP Forwarding im Tunnel selber, sprich Datenbank Client auf Datenbank IP.
Dadurch kann man dann klar sagen ob es ein externes oder internes Problem ist.
Klar wenn der Tunnel an sich weg ist ist auch der Tunnel interne Traffic weg. Spannend ist es aber wenn der Tunnelendpoint pingbar bleibt aber Tunnelintern nichts mehr. Dann hat es was mit dem PPTP Forwarding an sich zu tun.
Sorry wenn das verwirrend rüberkam.
und der Tunnel wird vom internen Microtik Router mit der IP 192.168.xxx.252 aufgebaut
Wie ist das jetzt gemeint. Jetzt wirds auch wieder etwas wirr.Macht der Mikrotik die IPsec und die PPTP Tunnelverbindung gemeinsam ?
Oder ist das auf unterschiedliche Router getrennt ?
In der Filiale versteht man dich dann so das der Bintec auch beides macht also IPsec und auch PPTP. Ist das denn richtig verstanden ?!
Tadaaaa !!! Das hatte ich gar nicht auf dem Radar. !!!
Danke für die Blumen ! 💐
And das an unserem Hausaufgaben Freitag !! 😄
D.h. es geht um die hohe Straße und dort werden sowohl IPsec als auch PPTP Tunnel bemeinsam vom Bintec bedient, richtig ?
P.S.: Du solltest ggf. beim Bild oben die Strassennamen entfernen um es zu anonymisieren !
Danke für die Blumen ! 💐
And das an unserem Hausaufgaben Freitag !! 😄
D.h. es geht um die hohe Straße und dort werden sowohl IPsec als auch PPTP Tunnel bemeinsam vom Bintec bedient, richtig ?
P.S.: Du solltest ggf. beim Bild oben die Strassennamen entfernen um es zu anonymisieren !
Auffällig sind da die auffällig vielen MTU Fehler "clamp MSS 1460 ==> 1410" !
Bist du dem mal nachgegangen ? Das sieht nach einem MTU Mismatch irgendwo in einem Tunnel Interface aus.
Ob das ursächlicher Fehler ist müsste man testen aber die Häufigkeit ist doch ein auffälliger Hinweis auf ein MTU bzw. MSS Problem. PPTP sollte immer mit einer MSS von 1412 betrieben werden.
Bist du dem mal nachgegangen ? Das sieht nach einem MTU Mismatch irgendwo in einem Tunnel Interface aus.
Ob das ursächlicher Fehler ist müsste man testen aber die Häufigkeit ist doch ein auffälliger Hinweis auf ein MTU bzw. MSS Problem. PPTP sollte immer mit einer MSS von 1412 betrieben werden.
Im Setup des Routers ! Dort muss die Tunnel MTU gesetzt werden auf dem virtuellen Tunnel Interface und auf dem lokalen LAN die MSS. Du kannst dir das an einem Cisco mal als Beispiel (IPsec VPN) ansehen.
interface Gigabit 1
description Lokales LAN
ip address 192.168.100.254 255.255.255.0
ip nat inside
ip tcp adjust-mss 1448
!
interface Dialer0
description xDSL Einwahl Interface Internet
mtu 1488
Oder HIER mit 1400 bei einem GRE Tunnel den ja auch PPTP für die Produktivdaten nutzt.
Passiert das ggf. häufiger wenn der PPTP Tunnel stark genutzt wird ?
Möglich das der Router dann durch den MTU/MSS Mismatch heftig in Software fragmentieren muss was dann zum Zusammenbruch des Tunnels führt.
Wasserdicht wirst du das aber wohl nur durch Trial and Error rausbekommen weil gute Debug Optionen auf dem Router (vermutlich) wenig bis gar nicht vorhanden sind, oder ? Alternativ ggf. mal ein Setup identisch zu den anderen störungsfreien Locations machen und den PPTP Tunnel auf einen MT auslagern. Ein 20 Euro hAP reicht für so einen Test.
interface Gigabit 1
description Lokales LAN
ip address 192.168.100.254 255.255.255.0
ip nat inside
ip tcp adjust-mss 1448
!
interface Dialer0
description xDSL Einwahl Interface Internet
mtu 1488
Oder HIER mit 1400 bei einem GRE Tunnel den ja auch PPTP für die Produktivdaten nutzt.
Passiert das ggf. häufiger wenn der PPTP Tunnel stark genutzt wird ?
Möglich das der Router dann durch den MTU/MSS Mismatch heftig in Software fragmentieren muss was dann zum Zusammenbruch des Tunnels führt.
Wasserdicht wirst du das aber wohl nur durch Trial and Error rausbekommen weil gute Debug Optionen auf dem Router (vermutlich) wenig bis gar nicht vorhanden sind, oder ? Alternativ ggf. mal ein Setup identisch zu den anderen störungsfreien Locations machen und den PPTP Tunnel auf einen MT auslagern. Ein 20 Euro hAP reicht für so einen Test.
Was mich wundert ist, was die AirPort Extreme hier zu suchen hat:
He he...das hatte ich mich auch gefragt war aber davon ausgegangen das du da noch einen Apple Accesspoint betreibst ! Er hat die vermutlich die 192.168.252.250 und will irgendwas mit HTTPS an die 172.217.23.34 senden.
Der ist vermutlich falsch konfiguriert als Router und nicht als einfacher Accesspoint. Das ist beim Apple Setup Tool etwas wirr gelöst.
Ggf. mal mit einem preiswerten_Profi_AP ersetzen.
Das mit der MTU ist schon sehr komisch. Kannst du wohl wieder rückgängig machen. Es geht auch nicht um die MTU sondern eher MSS. Das MSS Setting sollte aber im lokalen LAN Interface passieren. Siehe auch hier:
https://de.wikipedia.org/wiki/Maximum_Segment_Size
Gilt zudem auch nur für TCP Pakete.
Am PC bringt das auch rein gar nix, denn der macht ja gar kein PPTP. Das gilt nur dann wenn er selber PPTP macht. Deshalb geht das in die Hose.
Der PC selber "sieht" ja gar nichts vom PPTP Tunnel und seiner reduzierten MTU. Für ihn existiert nur Ethernet mit 1500er MTU und jutt iss. Das ist ja das fatale, deshalb setzen "schlaue" Router das MSS Clamping ein am Ethernet Port (nicht am WAN oder Tunnel Port) und erzwingen kleinere TCP Window Sizes damit um ein Fragmentieren zu verhindern.
Kann auch sein das das die Debug Message ist das der Router eben ein Clamping anzeigt bei jedem Frame der ihm zu groß ist und das mehr oder minder normal ist.
Es würde dann auch eher zu einem Performanceverlust im Durchsatz führen und nicht zu einem komplett Ausfall wie bei dir.
Der PC selber "sieht" ja gar nichts vom PPTP Tunnel und seiner reduzierten MTU. Für ihn existiert nur Ethernet mit 1500er MTU und jutt iss. Das ist ja das fatale, deshalb setzen "schlaue" Router das MSS Clamping ein am Ethernet Port (nicht am WAN oder Tunnel Port) und erzwingen kleinere TCP Window Sizes damit um ein Fragmentieren zu verhindern.
Kann auch sein das das die Debug Message ist das der Router eben ein Clamping anzeigt bei jedem Frame der ihm zu groß ist und das mehr oder minder normal ist.
Es würde dann auch eher zu einem Performanceverlust im Durchsatz führen und nicht zu einem komplett Ausfall wie bei dir.
Das Problem ist das der Debugg wirklich alles anzeigt was über den Router geht wie DNS and 8.8.8.8, Anfragen an WhatsApp, abgelaufenen RDP Sessions usw. usw. und was den Überblick trübt.
Relevant ist sowas hier:
12:07:54 DEBUG/INET: delete lru session, 192.168.254.253:1059->217.145.101.114:1723 prot: 6, current maximum: 4000
12:07:54 DEBUG/INET: destroy session, 217.145.101.114:0->192.168.254.253:47 prot: 47
12:07:54 DEBUG/INET: destroy session, 192.168.254.253:1059->217.145.101.114:1723 prot: 6
Das ist TCP 1723 und GRE also die PPTP relevanten Protokolle. 217.145.101.114 killt hier z.B. die Tunnelsession nachdem 192.168.254.253 das über die TCP 1723er Steuersession erzwungen hat.
Relevant ist sowas hier:
12:07:54 DEBUG/INET: delete lru session, 192.168.254.253:1059->217.145.101.114:1723 prot: 6, current maximum: 4000
12:07:54 DEBUG/INET: destroy session, 217.145.101.114:0->192.168.254.253:47 prot: 47
12:07:54 DEBUG/INET: destroy session, 192.168.254.253:1059->217.145.101.114:1723 prot: 6
Das ist TCP 1723 und GRE also die PPTP relevanten Protokolle. 217.145.101.114 killt hier z.B. die Tunnelsession nachdem 192.168.254.253 das über die TCP 1723er Steuersession erzwungen hat.