Fritz.Box - neue Subnetzmaske für funktionierenden VPN

[jurrasstoil]

Hey,

ich hab hier eine fritz.box 7312 die momentan mit der standard IP von 192.168.178.1, einer Maske von 255.255.255.0 und dem voreingestellten DHCP Bereich von .20-.200 fährt.

Jetzt hab ich via openvpn eine VPN Verbindung, jedoch reißt die alle 5-20 Minuten ab weil:

WARNING: potential route subnet conflict between local LAN [10.0.0.0/255.0.0.0] and remote VPN [10.101.1.1/255.255.255.255]

Der VPN vergibt 10.x.x.x Adressen.

Als Lösung für das Problem, soll ich jetzt die DHCP Range meines Routers ändern, auf 192.168.0.0 bis 192.168.255.255 zum Beispiel.
Wenn ich das jetzt aber so meiner fritz.box beibringen will, also Subnet von 255.255.0.0 und DHCP 192.168.0.1-192.168.255.255, dann krieg ich nur die Meldung:

Dies ist die Broadcast-Adresse des IPv4-Netzwerks. Sie kann hier nicht verwendet werden.

Hängt das mit den reservierten IP Adressen (192.168.180.1 bis 192.168.180.255) der fritz.box zusammen?

Könnte ich alternativ die IP der fritz.box auf 172.16.0.1 ändern und mit einem 172.16/12 Netz fahren? Also 172.16.0.0-172.31.255.255.

 

[rg88]

was willst du lokal mit so einem riesigen IP-bereich? Das problem steht aus meiner Sicht doch quasi da: Das lokale LAN (vom VPN?) deckt mit seiner Subnetzmaske alle 10.x.x.x Adressen ab. Das Remotenetz hat aber auch nen 10er bereich, deshalb meldet die Software konflikte. oder seh ich da was falsch. natürlich kannst du an der Fritzbox ip-adresse umstellen wie du willst, aber das ist doch nicht das Problem bei der Verbindung. Da ist doch eher am VPN was zu machen.
Mir erschließt sich halt nicht ganz der Sinn der Aktion mit dem großern 192.168.x.x Bereich?

 

[Merle]

Du kannst dem DHCP niemals sagen, er soll .0 ode .255 vergeben. In deinem Beispiel müsste es 192.168.0.1-192.168.255.254 sein. Denn die .0 ist reserviert (Netzadresse) und die .255 ebenso (Broadcast) laut Protokoll.
Aber rg88 hat völlig recht, das ist nicht das Problem.

 

[jurrasstoil]

Diese "Lösung" wurde mir so vom Support des VPN-Anbieters zugetragen. Ich persönlich sehe die Verbindung zwischen dem oben erwähnten Fehler und meinem lokalen LAN (und dessen DHCP range) auch nicht, bin aber leider auch kein Experte auf dem Gebiet.

Vielleicht hab ich auch was falsch verstanden, so sieht zumindest der Vorschlag im Original aus:

I believe I have pinpointed the issue.

Your logs shows this error: WARNING: potential route subnet conflict between local LAN [10.0.0.0/255.0.0.0] and remote VPN [10.101.1.1/255.255.255.255]

This indicates a subnet clash between your system and our VPN. The TAP adapter for our software configures a 10.x.x.x connection that all VPN traffic is routed through. If you change your default gateway / network DHCP range in your router to (172.16.0.0 - 172.31.255.255 or 192.168.0.0 - 192.168.255.255) , this should fix the issue.

 

[Raijin]

Grundsätzlich sollte man bei VPN-Verbindungen jedweder Art die Standard-Subnetze von Fritzboxxen, Speedports und Co meiden. Das heißt, dass es dringend anzuraten ist, dass du dein heimisches Subnetz NICHT auf 192.168.0.0/24 , 192.168.1.0/24 , 192.168.2.0/24 bzw. 192.168.178.0/24 setzt, sondern ein anderes wählst. Nimm etwas Ungewöhnliches. Haben nämliche beide LANs hinter den VPN-Gateways dasselbe Subnetz, dann funktioniert das Routing nicht. Deswegen sind die Standardsubnetze von Fritze und Co "gefährlich", weil weit verbreitet.

Hier kannst du dich austoben:

192.168.0.0 - 192.168.255.255
172.16.0.0 - 172.31.255.255
10.0.0.0 - 10.255.255.255

Brauchbare Subentze wären beispielsweise:

192.168.147.0/24
172.23.48.0/24
10.163.207.0/24


Das was der Support anspricht ist einfach zu erklären: Die Fehlermeldung deutet darauf hin, dass es einen Konflikt zwischen dem LAN und dem VPN gibt. Es wird also angenommen, dass die Fritzbox als LAN-Subnetz etwas ähnliches verwendet wie für das VPN. Daher der Rat, das LAN umzustellen. Du musst da aber nicht den kompletten Bereich abdecken, der in der Mail angegeben wurde. Das ist nur der mögliche Bereich.

Check mal folgendes:

ipconfig /all
route print

Wenn dort OHNE Verbindung zum VPN etwas mit 10.x.x.x auftaucht, dann ist das der Konflikt.

 

[Merle]

Er stellt aber seinen DHCP auf .1-.255 ein! Und das geht nicht! .255 is Broadcast und reserved.
Also, dein Netz darf sein (ich nehm mal ein Beispiel): 192.168.99.0 mit Subnetzmaske 255.255.255.0.
Der Router bekommt die 192.168.99.1.
dein DHCP wird eingestellt auf 192.168.99.10 - 192.168.99.200.
So wäre es ein richtiges Beispiel.

 

[Raijin]

ich hab hier eine fritz.box 7312 die momentan mit der standard IP von 192.168.178.1, einer Maske von 255.255.255.0 und dem voreingestellten DHCP Bereich von .20-.200 fährt.

Danach zu urteilen steht die Fritzbox aktuell noch auf Werkseinstellung. Ich gebe dir aber insofern Recht, dass man bei der Änderung des Subnetzes selbstverständlich darauf achten muss wie man die DHCP-Range konfiguriert.

 

[jurrasstoil]

Hab also mal im Sinne der Problemfindung die IP und DHCP Range entsprechend geändert (172.23.48/24 wie vorgeschlagen). Hat nichts gebracht.

Was jedoch etwas gebracht hat und mich der tatsächlichen Lösung aber nicht wirklich näher bringt, ist es der LAN Verbindung eine feste IP zuzuweisen. Also in Windows und im Router. So läuft die LAN Verbindung jetzt mit 172.23.48.22 und ich habe ohne die VPN Verbindung keine Verbindung zum Internet. Mit der VPN Verbindung jedoch schon und diese reißt nun ähnlich wie vorher, aber nun statt alle 5-20 Minuten unregelmäßig alle paar Stunden ab.
Leider spucken die logs zum Zeitpunkt des Verbindungsabbruchs keinerlei Fehler aus, was die Suche nach der Ursache ziemlich erschwert. So ist es zwar nun ein wenig erträglicher, aber immer noch weit entfernt von optimal.

 

[Raijin]

ipconfig /all
route print

Ich zitiere mich ungern selbst, aber gib die Befehle bitte mal in der Eingabeaufforderung ein - mit und ohne VPN - und mach Screenshots davon, die dann hochlädst. Deine IP-Konfiguration scheint ziemlicher Käse zu sein, wenn ich das mal so sagen darf

 

[jurrasstoil]

Die default Einstellungen die ich vorher hatte liefen ja problemlos. Mit dem VPN machen sie aber Probleme und ob es nun an der VPN Software, bzw. dem VPN selbst oder an irgendeiner Einstellung irgendwo in Windows, dem Router oder der Software liegt lässt sich auch nicht sagen. Da bleibt mir ja nicht viel übrig ausser rumprobieren, wenn es keine eindeutigen Fehlermeldungen gibt die auf die Ursache hinweisen. Das mit der festen IP hat ja zumindest Besserung gebracht, wenn es auch weit entfernt von optimal ist, aber bis der eigentliche Fehler gefunden ist muss ich mich zumindest nicht mit Verbindgsabrissen alle 5-20 Minuten rumschlagen.

Ohne VPN, mit dynamischer IP
Mit VPN und dynamischer IP

Ohne VPN, mit fester IP
Mit VPN und fester IP

Der mögliche subnet conflict taucht im openvpn.log auch seit dem 2. Mai nicht mehr auf.

//edit

Problem gelöst. Der Client benutzte als default immer den Port 8080, aber keines der vorhandenen logs beschwerte sich auch nur ansatzweise über irgendwas bzgl. des Ports. Jetzt läuft es mit Port 1194 und macht keinerlei Probleme mehr. Und natürlich läuft die LAN Verbindung jetzt wieder ohne feste IP, warum das allerdings beim 8080 Port eine deutliche Besserung brachte... keine Ahnung.