mitch123
Goto Top

Fritzbox: VPN-Problem nach Zwangstrennung mit NAT

Ich benutze 2 Fritzboxen an verschiedenen Standorten, um einen VPN-Tunnel herzustellen und die Remotenetze mittels LAN-LAN-Kopplung miteinander zu verbinden. Sowohl Ping als auch TCP-basierte Verbindungen funktionieren problemlos bis zur DSL-Zwangstrennung.

Nach Wederaufbau des VPN-Tunnels funktioniert zwar wieder der Ping von einem LAN zum anderen, aber bei einigen TCP-Verbindungen (zB SQL Port 3306) wird durch eine der beiden Fritzboxen der TCP-Port des Servers verändert (vermutlich durch NAT) von 3306 auf zB. 61004. Eigentlich sollte im Falle eines Tunnels kein NAT angewendet werden , was auch im Regelbetrieb nicht vorkommt. Aber nach einigen Zwangstrennungen wird der Port dennoch verändert. Eigentlich sollte der Port weiterhin 3306 bleiben.

Da sich meine Linuxkenntnisse leider auf rudimentäre Befehle beschränken bin ich auf Hilfe angewiesen. Die Firma AVM bleibt mir bislang eine Aussagekräftige Antwort schuldig. Hat jmd. eine Idee, welcher Mechanismus das nicht-gewollte NAT verursacht und wie man dieses Phänomen vermeiden kann.

Content-ID: 274606

Url: https://administrator.de/forum/fritzbox-vpn-problem-nach-zwangstrennung-mit-nat-274606.html

Ausgedruckt am: 22.12.2024 um 21:12 Uhr

aqui
aqui 15.06.2015 um 13:30:12 Uhr
Goto Top
wird durch eine der beiden Fritzboxen der TCP-Port des Servers verändert (vermutlich durch NAT)
Sorry, aber das ist technischer Unsinn ! NAT verändert niemals die TCP oder UDP Ports sondern einzig nur die Layer 3 IP Adressen !
Woher weisst du das ? Hast du mit dem Wireshark mitgesniffert ?
Sollte dem wirklich so sein und ist das im Sniffertrace sichtbar, dann ist das eindeutig ein Bug der Firmware. Es darf doch niemals der Ziel Port verändert werden, denn dann ist der Traffic niemals mehr einer Applikation am Zielsystem zuortbar und würde den sofortigen Stillstand und Abbruch der Kommunikation bedeuten.
Ausserdem ist deinen Vermutung absolut korrekt, denn der VPN Tunnel selber ist vom NAT Prozess ausgenommen. Das muss auch so sein, denn sonst wäre eine transparente Kommunikation beider Seiten bei einer LAN zu LAN Kopplung unmöglich !
Stimmt das alles was du sagst hier müsste man einen Firmware Bug annehmen.
Ist deine Firmware auf dem aktuellsten Stand ?
Mitch123
Mitch123 15.06.2015 aktualisiert um 14:27:11 Uhr
Goto Top
Ich habe einen Mitschnitt des Datenverkehrs im korrekten Zustand (Port bleibt unverändert ) und im Fehlerfall (Serverport wird verändert).
Den Mitschnitt habe ich am Eingang der Box beim Server und am SQL-CLIENT auf der anderen Seite des Tunnels gemacht. Ganz konkret wird das vom Server kommende SYN-ACK durch eine der beiden Boxen geändert und somit kommt kein 3Wege-Handshake zustande.

Leider War ein erste Aussage von AVM , dass es nicht an der Fritzbox liegt, weil ja der Ping funktioniert.

Firmware ist up to date.
Mitch123
Mitch123 15.06.2015 aktualisiert um 21:07:58 Uhr
Goto Top
Und leider muss ich dir ein wenig widersprechen. Wenn du ein Netz mit NAT maskierst und zwei verschiedene PC mit zufällig gleichem Quellport auf ein Ziel zugreifen, muss der Router die Ports nach draussen verändern. Ansonsten können die Antwortpakete nicht sauber einem Client zugeordnet werden.

Ich finde nur nicht sinnvoll NAT über den VPN-Tunnel aufzubauen. Ich würde mir gern die iptables anschauen, um ggf den Fehler weiter einzugrenzen. Aber mein beschränktes Linux-Fritzbox-Wissen lässt mich auch mit find kein iptables finden. Wer kann helfen?
aqui
aqui 16.06.2015 um 09:33:01 Uhr
Goto Top
Du hast zweifelsohne Recht was die Source Ports anbetrifft. Klar, die werden wie auch die Source Adresse umgeschrieben, das steht außer Frage.
Oben redest du aber von den Destination Ports und die können unmöglich umgeschrieben werden. Ggf. war das missverständlich sorry.
Die Source Ports sind aber für die Kommunikation vollkommen uninteressant.
Und ja du hast Recht NAT im VPN Tunnel ist völliger Blödsinn und auch kontraproduktiv, denn so ist keine saubere geroutete Kommunikation zwischen den via VPN gekoppelten LAN Netzen mehr möglich. Kein Mensch macht so einen Unsinn, da hast du Recht.
Ob du iptables Regeln aktiv hast kannst du mit iptables -L checken.
Mitch123
Mitch123 16.06.2015 aktualisiert um 10:38:29 Uhr
Goto Top
Damit hab ich leider bei der Fritzbox ein Problem. Den Befehl iptables kennt er nicht und den gibt's auch nicht in der Usr/bin oder usr/sein. .. als prompt bekomme ich die Rute # . Muss ich noch irgendeinen Modus im Linux wechseln? Wie gesagt ich habe null Linux peil. ..

Was NAT angeht gebe ich dir recht, avm hat es mittlerweile an die Netzwerker weitergegeben.
aqui
aqui 16.06.2015 um 14:39:59 Uhr
Goto Top
Den Befehl iptables kennt er nicht und den gibt's auch nicht in der Usr/bin oder usr/sein
Hast du deine Fritzbox gefreetzt ?? Auf die Linux Shell einer originalen FB hast du ja keinen Zugriff !
Mitch123
Mitch123 16.06.2015 um 14:59:41 Uhr
Goto Top
Ach schade. Damit verliere ich ja dann Ansprüche auf Unterstützung durch AVM. Aber werde wohl nicht drum rum kommen.
aqui
aqui 16.06.2015 um 15:29:12 Uhr
Goto Top
Bahnhof ?? Was sollen uns diese kryptischen, wirren Worte jetzt sagen ??
Mitch123
Mitch123 03.07.2015 um 08:39:57 Uhr
Goto Top
Nachdem ich mich zum Second-Level bei AVM vorgearbeitet und mehrfach Mitschnitte ausgetauscht habe, wurde mir die neueste Laborversion für den 7490 ans Herz gelegt, die mein Problem tatsächlich behebt. Somit ist der Thread dann geschlossen ohne genau zu wissen, warum der Fehler verursacht wurde face-smile