[Problem] VPN Verbindung zw. FritzBox 7490 und 7390 bricht ab

[Shirocco88]

Solange die gezeigten Konfigurationsdateien tatsächlich die richtigen sind (insb. bei den "accesslist"-Einträgen), gibt es keinen ersichtlichen Grund, warum die Daten (UDP an Port 4500 oder 500) durch den Tunnel zum Peer gesendet werden sollten. Das wäre nur dadurch zu erklären, daß alle Daten durch den Tunnel gesendet werden sollen (also eine "any any"-Rule) und dabei die IKE-Pakete nicht davon ausgenommen werden (mit einer "deny"-Regel für UDP 4500 und 500 - wobei beim Versuch, UDP 4500 ebenfalls über den Tunnel zu senden, eigentlich gar keine VPN-Verbindung funktionieren dürfte).

Idee um "sinnfreie" VPN-Verbindungs-Versuche (Port 500) zu verhindern, sowie Stabilisierung der VPN-IPsec NAT-T Verbindungen zu implemetieren:

Portforwarding @Speedport-Router einrichten:
==> UDP/Port 500 nach "Black Hole", z.B. 192.168.2.77, UDP/Port 500
==> UDP/Port 4500 nach FB7390: (192.168.2.1, UDP/Port 4500)
==> keine Exposed-Host Configuration nach FB7390 (IP: 192.168.2.1)
einrichten.

Dann sollte die FB7390 nicht mehr auf den Einfall kommen eine Verbindung via UDP-Port 500 aufbauen zu wollen.

 

[PeterPawn]

Der Speedport-Router benutzt aber offensichtlich ein anderes eigenes Netz (192.168.10.0/24) - da haben Adressen aus 192.168.2.0/24 nichts mit zu tun.

Solange es keine weiteren eingehenden Dienste gibt, wäre es zumindest eine Idee, an die Stelle von "exposed host" mal als Test tatsächlich auch auf NAT zu setzen ... weitere Maßnahmen (insb. das "black holing" von UDP 500 oder eine Weiterleitung von UDP 4500) sollten gar nicht notwendig sein, es ist vollkommen in Ordnung, wenn der SP sie abblockt (wozu sollte es die Weiterleitung brauchen, wenn die 7390 nicht passiv erreichbar ist). ESP oder AH (beides gesonderte IP-Protokolle, für die es i.d.R. kein NAT in einem Router gibt -> die arbeiten ohne Ports und auch ein Austausch von Adressen invalidiert das Paket, daher ja die Einführung von NAT-T beim IPSec) braucht es bei NAT-T dann auch nicht.

Die FRITZ!Box 7390 sollte als Initiator von sich aus nach dem beim ersten Versuch auf UDP-Port 500, der dann ganz normal per NAT auf irgendeinen unbestimmten Port umgesetzt wird, senden und bei der ersten Antwort schalten dann beide auf NAT-T um und die 7390 sendet ihrerseits erneut, diesmal dann gleich an den Port 4500 der 7490 (bei ihr bleibt es bei irgendeinem wahlfreien Port als Absender, auch wenn das wahrscheinlich ein anderer als beim ersten Versuch sein wird).

Ich schrieb ja bereits (vielleicht nicht deutlich genug), daß es denkbar wäre, daß der SP da irgendetwas mit einer Sonderbehandlung, die eigentlich für "IPSec Passthrough" o.ä. gedacht ist, machen könnte - ich kenne dessen Firmware an dieser Stelle praktisch nicht - und das durchaus auch die Ursache für irgendein Timeout nach einer definierten Zeit sein könnte.

Aber die korrekte Reihenfolge wäre es m.E. immer noch, zuerst einmal die Existenz so eines festen Zeitfensters festzustellen, bevor man sich an seine Lokalisierung macht.

Man kann natürlich auch (solange es nur um VPN hinter dem SP-Router geht) die 7390 gar nicht mehr als "exposed host" betreiben und damit die Topologie umbauen. Aus "Sicherheitssicht" wäre das sogar eine weitere Firewall, die man zwischen dem Internet und dem LAN "hochzieht", bei "exposed host" bietet ja nur die FRITZ!Box diesen Schutz.

 

[Pokemon20021]

wobei die 7390 hinter einem LTE Router Speedport LTE2 (der nur als Modem konfiguriert ist) sitzt.

Der Speedport-Router benutzt aber offensichtlich ein anderes eigenes Netz (192.168.10.0/24) - da haben Adressen aus 192.168.2.0/24 nichts mit zu tun.

irgendwas passt da nicht;
IMHO widersprechen sich #1 und #22

 

[PeterPawn]

Möglich ... da würde ich aber eher die Wortwahl in #1 als unglücklich betrachten - die schematische Darstellung (ich hoffe mal, daß die sich seit #1 nicht auch unbemerkt geändert hat) läßt da (m.E.) nur wenige Zweifel zu. Vielleicht interpretiere ich das auch falsch ... aber wenn die "DMZ" im SP die IP-Adresse 192.168.10.2 hat, fällt mir keine andere alternative Interpretation ein, als daß es sich dabei um die WAN-IP der 7390 handelt und das paßt auch ganz gut zu den letzten VPN-Protokollen.

 

[Nontschew]

Danke für Eure Antworten!

Das mit dem Port Forwarding kann ich gerne mal testen. Könnte ich im Speedport dann UDP/Port 4500 auch auf die FB7390 mit IP 192.168.10.2 umleiten. Oder muss dann die Fritzbox im Netz des Speedports sein?

WEnn ich die Exposed-Host Konfiguration in der jetzigen Topologie damit aufhebe, ist aber normales Internet usw. noch möglich? Von außen muss ich nicht weiter auf irgendwelche Dienste kommen, evtl. noch auf meine NAS. Aber diesen Port kann ich mir dann ja explizit auch weiter leiten. Ich hoffe ich habe da keinen Denkfehler...

 

[PeterPawn]

Außer "Portforwarding" klingt das zumindest alles noch nachvollziehbar - ich habe mich ja bemüht zu betonen (und zu erläutern), daß es so etwas im Speedport für das VPN gar nicht brauchen würde; da irritiert mich dessen neuerliche "Erwähnung" in diesem Kontext jetzt schon etwas.

 

[Pokemon20021]

BTW: die P1-IDs in #9 passen nicht

7390_DS-lite.txt

/*
 * cfg File - Fritbox 7390 - DS-Lite Verbindung
 * Mon Feb 13 17:43:49 2017
 */
SNIP
                name = "IPv4.selfhost.eu";
                remotehostname = "IPv4.selfhost.bz";
                localid {
                        fqdn = "DS-lite.selfhost.eu";
                }
                remoteid {
                        fqdn = "IPv4.selfhost.bz";        // Aktiver FQDN gemaess #19
                }

7490_IPv4.txt

/*
 * cfg-File für Fritzbox 7490 - IPv4-Verbindung
 * Mon Feb 13 17:43:49 2017
 */
SNIP
                name = "DS-Lite.selfhost.eu";
                localid {
                        fqdn = "IPv4.selfhost.[B][COLOR=#ff0000]eu[/COLOR][/B]";        // Klärung, hier sollte eigentlich "[COLOR=#0000ff]IPv4.selfhost.bz[/COLOR]" stehen
                }
                remoteid {
                        fqdn = "DS-Lite.selfhost.eu";
                }

unklar wie das funktionieren soll;
oder wurde da inzwischen ausser "CGN.selfhost.eu" auch noch geändert ?

 

[Nontschew]

Um die Missverständnisse mal auszuräumen:

Möglich ... da würde ich aber eher die Wortwahl in #1 als unglücklich betrachten - die schematische Darstellung (ich hoffe mal, daß die sich seit #1 nicht auch unbemerkt geändert hat) läßt da (m.E.) nur wenige Zweifel zu.

Es ist wie PeterPawn schreibt, ich habe mich da unglücklich ausgedrückt, die schematische Darstellung ist genau richtig und entspricht nach wie vor der Topologie.

unklar wie das funktionieren soll;
oder wurde da inzwischen ausser "CGN.selfhost.eu" auch noch geändert ?

die einträge hier sind nicht die echten, die habe ich geändert. In den orginalen stimmt das alles überein...

Ich habe jetzt mal die Exposed-Host Konfiguration geändert und nur 4500 weiter geleitet. MAl sehen ob es was bringt...

 

[PeterPawn]

Ich habe jetzt mal die Exposed-Host Konfiguration geändert und nur 4500 weiter geleitet. MAl sehen ob es was bringt...

Und warum genau hast Du den UDP-Port 4500 jetzt weitergeleitet? Was willst Du damit erreichen - bei der aktuellen Konfiguration?

 

[Nontschew]

Ja, mit dem was du geschrieben hast ist das tatsächlich sinnfrei. Es funktioniert auch so, ohne die Weiterleitung an Port 4500 und ohne DMZ.

Allerdingab wird die Verbindung tatsächlich wieder getrennt. Bei meinem jetzigen versuch, wie bekannt nach genau einer Stunde....

 

[Pokemon20021]

Allerdingab wird die Verbindung tatsächlich wieder getrennt. Bei meinem jetzigen versuch, wie bekannt nach genau einer Stunde....

Zur Problemeingrenzung fehlt noch die Traffic-Analyse:

Da wirst Du um einen Paketmitschnitt zum richtigen Zeitpunkt nicht herumkommen und ob der dann wirklich hilft, muß sich auch erst noch zeigen.

Also brauchst Du wohl den jeweiligen (parallelen) Mitschnitt auf dem externen Interface der FRITZ!Boxen beim Auftreten des Problems (wenn das tatsächlich reproduzierbar ist mit festem Timing, ist das ja keine Hürde), damit man zumindest sehen kann, ob und ggf. sogar wo die Pakete nun versanden.

... beim Mitschnitt der IPSec-Pakete kann man auf der "1. Internetverbindung" die verschlüsselten Pakete (quasi in der Umverpackung) sehen und auf der "Routing-Schnittstelle" die bereits entschlüsselten. Letztere sind sicherlich besser zu untersuchen, aber die anderen sollte man parallel auch mitschneiden, weil die auf der "Routing-Schnittstelle" natürlich nur nach erfolgreicher Entschlüsselung erscheinen.

welche IP-Adresse die 7390 wohl als ihre eigene senden mag - das kann man auch einem Mitschnitt entnehmen, wenn man die Cookies kennt und die Hash-Berechnung dann einfach für die "Kandidaten" selbst ausführt und mit dem gesendeten Wert vergleicht

... dem Protokoll der 7390 nach wollte diese vor 03:36 ja wieder diesen "Rückschritt" machen, im Protokoll der 7490 fehlt der Teil wieder), muß dann eben ein Paketmitschnitt auf beiden Seiten her und zwar auch hier ein zeitgleicher.

Ich habe es in diesem Thread nicht noch einmal gesondert betont, aber zur Fehlersuche bei einer VPN-Verbindung gehört generell einfach ein zeitgleiches Vorgehen (am besten ein Neustart) auf beiden Seiten und dann eben auch das zeitgleiche Protokoll (und der Mitschnitt, wenn man einen anfertigt) von beiden Seiten.

siehe:
http://www.wehavemorefun.de/fritzbox/Paketmitschnitt
https://www.youtube.com/watch?v=erHYfCAB8Ig

Ziel ist es zu prüfen, welche Protokolle (50 (ESP), UDP/Port 500, UDP/Port 4500) trasportiert werden und wie sich die Fritzbox bei Dead-Peer-Situationen sowie Rekeying verhält.

 

[Nontschew]

Danke Pokemon20021! Ich hatte das ja alles gelesen, da ich allerdings nicht wusste wie ich das anstellen sollte, hilft mir das jetzt wirklich weiter.
Ich werde das also wie im link beschrieben zeitgleich auf beiden Fritzboxen mitschneiden und beide am Anfang neu starten.
Wenn ich es richtig im Kopf habe, hättest du geschrieben, Mitschnitt mindestens >2,5h.

Bin aktuell im Urlaub und werde das am Mittwoch Abend machen und hier zur Verfügung stellen.

Danke allen erst mal für eure Hilfe und eure Geduld mit mir!

 

[PeterPawn]

Erst den Zeitpunkt des (wahrscheinlichen) nächsten Fehlers bestimmen und dann kurz vorher den Mitschnitt starten ... kein Mensch will sich 2,5 h Netzwerkdaten von einem halbwegs benutzten Anschluß ansehen und die erste Viertelstunde schon mit dem Suchen der richtigen Stelle im Mitschnitt verbringen.

Genau deshalb habe ich immer wieder darauf verwiesen, daß es wichtig ist, einen reproduzierbaren Zeitpunkt zu ermitteln - bei einem Mitschnitt über 2,5 h wäre der Mitschneidende vermutlich auf sich selbst gestellt; zumindest bei der Extraktion der Daten zum IPSec auf dem ganzen Wust.

 

[Nontschew]

**** GELÖST ****

Auch wenn nun doch etwas Zeit vergangen ist, möchte ich hier dennoch die Lösung zu dem geschilderten Problem noch kundtun.

Nach dem ich den Mitschnitt der Schnittstellen gleichzeitig auf beiden Seiten zum richtigen Zeitpunkt gefühlt 4x versucht habe, die Verbindung aber genau da nicht abgebrochen ist, habe ich alles auf eine Karte gesetzt.
Und zwar habe ich den Speedport LTE2 durch eine Fritzbox 6840 ersetzt und dieser das VPN cfg-File (siehe #9) eingepflanzt.

Konfiguration sieht jetzt wie folgt aus:
Anhang anzeigen Konfiguration_Schema_neu.pdf

Ergebnis ist nun, dass die VPN Verbindung weiterhin problemlos aufgebaut wird, jetzt aber absolut stabil steht und es keine Abbrüche oder Fehlermeldungen mehr gibt. Funktioniert jetzt so seit einer Woche. Die 7490 macht Nachts zw. 3 und 4 Uhr eine Zwangstrennung, ca 1 Minute später steht die VPN Verbindung wieder und bleibt dauerhaft bis zur nächsten Zwangstrennung. Kurz: Es funktioniert perfekt!

Heißt für mich, dass der Speedport LTE tatsächlich in irgendeiner Weise rein gefunkt hat und daher die Verbindung nicht stabil blieb. Da der Speedport nur gemietet war, geht der jetzt zurück an die Telekom.

In diesem Sinne möchte ich mich ganz herzlich für die Unterstützung bei PeterPawn, Pokemon20021 sowie Micha0815 bedanken. Eure Hinweise haben mir auf jeden Fall bei der Fehlereingrenzung geholfen, sowie ein tieferes Verständnis zum Aufbau des cfg-Files beigetragen.

Beste Grüße und nochmals vielen DANK!
Nontschew