OpenVPN erhält eigene DHCP-IP in FritzBox

Black

Junior Member
Hallo,

ich habe aktuell ein kurioses Problem, was ich bis vor ein paar Wochen definitiv noch nicht hatte. Ich betreibe eine FritzBox 7490 mit aktueller Beta-Firmware, daran angeschlossen ist mein Rechner via LAN-Kabel.

Ohne OpenVPN wird meinem Rechner eine feste DHCP-IP zugewiesen mit der dazugehörigen MAC von dem Netzwerkchip des Mainboards. Wenn ich aber eine OpenVPN-Verbindung mit dem aktuellen OVPN-Client (nicht der VPN Manager!) starte, dann passieren zwei seltsame Dinge.

1. Es braucht einige Anläufe, bis die "TEST ROUTES" durch sind, manchmal zwei, manchmal 5.

Sat Oct 17 02:10:56 2015 us=996499 TEST ROUTES: 0/0 succeeded len=0 ret=0 a=0 u/d=down
Sat Oct 17 02:10:56 2015 us=996499 Route: Waiting for TUN/TAP interface to come up...
Sat Oct 17 02:10:58 2015 us=115934 TEST ROUTES: 0/0 succeeded len=0 ret=0 a=0 u/d=down
Sat Oct 17 02:10:58 2015 us=115934 Route: Waiting for TUN/TAP interface to come up...
Sat Oct 17 02:10:59 2015 us=355792 TEST ROUTES: 1/1 succeeded len=0 ret=1 a=0 u/d=up

2. Dem TAP-Adapter von OVPN wird im Router eine eigene DHCP-IP zugewiesen, die MAC passt zum Adapter. Wenn die Verbindung jedoch einmal hergestellt ist, dann verschwindet das Netzwerkgerät in der Fritzbox bzw ist inaktiv, stelle ich dann erneut eine OVPN-Verbindung her, dann erscheint das Gerät wieder.

Das ist jetzt nicht wirklich schlimm, leider habe ich seitdem auch eine instabile OVPN-Verbindung, die andauernd abbricht, manchmal aber auch nicht, wie jetzt gerade. Ich kann mir einfach keinen Reim drauf machen.

Es kann doch eigentlich nur ein Bug in der Fritzbox Beta-Firmware sein, aber wieso sollte dann der OVPN-Adapter eine eigene IP zugewiesen bekommen?

OVPN wurde bereits neu installiert, die config Files sind aktuell, Firewall und Antivirus wurden probeweise deaktiviert und das Internet läuft auch ohne Probleme. Andere Netzwerkgeräte wie Smartphone werden auch nur ein Mal als Netzwerkgerät gelistete, nur der Rechner wird bei einer OVPN-Verbindung doppelt gelistet bzw. mit MAC des TAP-Adapters.

Bei den Details zum Netzwerkgerät gibt es folgende Unterschiede:

Rechner (Netzwerkkarte) - über LAN1 - Fritzbox
Rechner (OVPN-Adapter) - Rechner (Netzwerkkarte) - über LAN1 - Fritzbox

JackCarver und Co: eine Idee, was das sein kann?
 
Ist definitiv seltsam, da der TAP Adapter ja nur ein virtuelles Netzwerk-Interface ist. Davon sollte eigentlich der Router nix mitbekommen, physisch ist er ja lediglich mit der LAN Karte verbunden, die sich bei diesem anmeldet. Gut wenn der TAP Adapter tatsächlich per DHCP ne IP vom Router zugewiesen bekommt, dann wird dieser vermutlich nach VPN Einwahl genau deswegen als inaktiv angezeigt, da er dann vom PP Server ne eigene IP zugewiesen bekommt, die nicht zu deinem LAN gehört.

Testweise würde ich einfach mal DHCP abschalten und feste IPs vergeben. Dann teste mal wie es sich mit der Stabilität von OVPN verhält, ist es dann wieder i.O., dann liegt es vermutlich an der Beta. Möglicherweise kannst du dann ja n Downgrade der Firmware machen.
 
Danke für deine Antwort, Jack!

Ich würde gerne eine frühere Labor-Firmware einspielen, die bietet AVM leider nicht an, nur die aktuelle. Ein Downgrade auf das offizielle Fritz OS ist auch nur mit Recover möglich, würde ich also nur machen, wenn es keine andere Möglichkeit mehr gibt.

Ich würde nur gerne verstehen, wie es sein kann, dass der Router überhaupt die MAC-Adresse des virtuellen TAP-Adapters sehen und loggen kann, denn wie du schon sagtest sollte der Router davon ja nichts mitbekommen. Der Aufbau der VPN-Verbindung sieht grob doch wie folgt aus:

1. Wenn der Tunnel über die Domain aufgebaut wird, dann wird über DNS die IP-Adresse vom OVPN-Server angefragt, dies geschieht über den Adapter meiner physischen Netzwerkkarte.
2. OVPN erhält die Antwort vom DNS Server, und handelt dann die Verbindung zwischen Client und VPN-Server über die physische Netzwerkkarte aus.
3. Wenn die Verbindung steht und mit TEST ROUTES erfolgreich getestet wurde, dann werden auf dem Client die ROUTES mit Adminrechten so umgeschrieben, dass jeglicher Traffic über das virtuelle Netzwerk über den virtuellen Adapter laufen. Dieser Adapter wird aber zu 100% über den physischen Adapter geleitet, der Adapter ist nur dem Client-Rechner und dem VPN-Server bekannt. Die Verbindung selbst ist ja nur eine SSL-verschlüsselte Verbindung, in die niemand ohne den richtigen Schlüssel hineinblicken kann, äußerlich kann man nur die UDP-Daten wie Ursprungs-IP und Ziel-IP sehen.

Wie kann es also sein, dass mein Router die MAC-Adresse vom virtuellen TAP-Adapter sehen kann. Da muss doch was in meinem Windows falsch laufen? Selbst wenn die Router Firmware einen Bug hat, dann kann sie doch nicht irgendwie die MAC-Adresse von Adapter anfragen, von denen sie eigentlich keine Ahnung haben sollte?

Ich schicke dir mal das Log per PN, Jack. Da sind ein paar Errors drin, vll. sagen dir die mehr als mir, zB das hier: "Notified TAP-Windows driver to set a DHCP IP/netmask of ...", ist das normal?
 
Diese Meldung ist normal, sagt ja nur aus, für welches Subnetz das TAP interface konfiguriert wird, nämlich für 10.17.11.8/255.255.255.128. Der einzige Error kommt weiter unten und betrifft den ipconfig Befehl. Das hat aber alles nichts mit dem Verhalten des Routers zu tun, diese Vorgänge betreffen ja rein Windows.

Der Ablauf bei DHCP ist ja grob, dass sich der Client über sein Netzwerkinterface am DHCP Server anmeldet und um Vergabe einer unbenutzten IP bittet. Der Client bekommt dann vom Server die IP mit zugehöriger Lease, also wann diese abläuft. Es scheint sich also nach erfolgter LAN Verbindung ebenfalls der TAP Adapter beim Router zu melden und um Vergabe einer IP zu bitten. Dazu sendet er auch seine MAC an den Router, wodurch dieser diese erkennt.

Warum das vorher nicht war oder ob das jetzt seit nem TAP Treiber Update der Fall ist kann ich nicht sagen. Evtl hat der Router vorher Anfragen von virtuellen Devices ignoriert, was er jetzt nicht mehr macht, oder der TAP Adapter hat vorher keine Anfrage gestellt. Irgendwas davon muss es sein.
 
Danke für die Hilfe!

Also was bleibt mir jetzt übrig? Windows neu installieren? Ich habe den LAN-Treiber, OVPN, TAP und den Intel INF-"Treiber" neu installiert. Folgende Dinge sind mir noch aufgefallen:

1. Ich habe meine Fritzbox vor einiger Zeit in "FritzboxNEU" umbenannt, damals hieß sie "FritzboxALT". Zudem hatte ich eine WLAN-Karte via USB am Rechner, mein WLAN-Netz hieß "FritzboxALT-2,4GHz". Damals hat mich gewundert, dass beim LAN-Adapter immer der Name des WLAN-Netzwerks stand und nicht der Name des Gateways, also "FritzboxALT" oder aktuell "FritzboxNEU". Der WLAN-Treiber und die Karte sind längst nicht mehr in Betrieb, aber irgendwie hat er sich den Namen vom WLAN-Netz gemerkt und beim LAN-Treiber steht immer noch "FritzboxALT-2,4GHz", also der Name des uralten WLAN.

2. Mir ist eingefallen, dass die Sache mit dem zweiten Client in der Fritzbox erst vorhanden ist, seitdem ich eine Fritzbox 7272 hinter der 7490 im IP-Client-Modus betreibe, also als reinen Switch, der alles an die 7490 weiterleitet. Um diese Konfiguration als Fehlerursache auszuschließen, habe ich diese aber natürlich nicht mehr im Betrieb und mein Rechner hängt direkt an der 7490. Vielleicht ist ja in meinem Windows irgendwie was davon hängengeblieben?
 
Hast du irgendne virtuelle Maschine noch am Laufen bzw bridged Netzwerk Einstellungen am TAP Adapter? Also ich denke zu 90% kann man den Router ausschließen, der tut nur seinen Job und beliefert anfragende Clients mit IPs. Am Intel Treiber sollte das auch nicht liegen, verbleibt OVPN/TAP, mit Schwerpunkt auf TAP. Ideal wäre jetzt n zweites System zum Testen, sollte natürlich auch n Windows System mit TAP Adapter sein um Vergleiche ziehen zu können.
 
Ich habe zwar virtuelle Maschinen, die laufen aber über NAT und sind nicht aktiv. Ein zweiter Windows Rechner ist leider nicht vorhanden.

Wenn man die Fehlermeldungen von OVPN googelt, dann fällt des öfteren das Wort "DHCP", sei es beim Fehlschlagen von TEST ROUTES oder auch von "ERROR: Windows ipconfig command failed: returned error code 2".

Ich glaube langsam, dass es doch an der Fritzbox liegt und nicht an Windows, eine Sache habe ich noch nicht ausprobiert: FB vom Strom trennen. Habe sie zwar 100 Mal neugestartet, aber vom Strom trennen bewirkt manchmal Wunder! Bei meiner alten 7390 hat reines Neustarten nichts gebracht, erst der Stromverlust hat das Problem beseitigt.

Wünsch mir Glück, bin gleich zurück.

EDIT: hat nichts gebracht. Aktuell ist es einigermaßen stabil, ich denke ich warte auf eine neue Beta Firmware in der nächsten Woche.
 
Last edited:
Du musst aber hierbei unterscheiden, ob das DHCP vom OVPN Server gemeint ist, denn der fungiert für den VPN Client ja ebenfalls als DHCP Server oder der DHCP vom Router. Die OpenVPN IP bezieht der Client in jedem Fall per DHCP vom OVPN Server.
Der TAP Adapter scheint aber auch bei der FB um ne IP zu bitten, da ich kein Win derzeit am Laufen habe, kann ich hier aber auch nicht quertesten.

Evtl hilft ja das Trennen vom Strom.
 
Habe Windows 10 komplett frisch auf mein Hostsystem installiert, die ersten 3 Connections sind optimal verlaufen, doch beim vierten Mal kam wieder der Mist mit dem "TUN/TAP-Adapter is waiting". Es liegt also definitiv nicht an meinem Windows, könnte clientseitig höchstens noch das BIOS sein, was einen Bug mit dem Netzwerkchip aufweist, wäre nicht das erste Mal, dass das BIOS unerklärliche Probleme bereitet trotz x99-Premiumsuperduperchipsatz!

Ich gehe aber stark davon aus, dass die FB Firmware verbuggt ist, eventuell hat auch das Vorschalten der FB7272 den Bug ausgelöst, der sich jetzt festgefressen hat, sodass auch das entfernen der FB7272 nichts mehr bringt.

Wenigstens sind die Verbindungsabbrüche bisher nicht mehr aufgetreten. Bleibt mir also nur, auf ein Firmware-Update zu warten. Naja, zumindest bin ich jetzt auf Windows 10 unterwegs, das wollte ich eh schon länger mal ausprobieren.
 
Habe nun auch die beiden Fritzboxen komplett zurückgesetzt, alles händisch ohne Backup neu eingerichtet, aber das Problem bleibt. Ich konnte noch nichtmal die 7272 als reinen AP einrichten, indem ich ihr DHCP abgedreht habe und eine IP aus dem 7490-Netz vergeben habe. Jetzt läuft sie mit mehreren Anläufen wieder im IP-Client-Modus. Mit der 7490 Firmware läuft etwas gewaltig schief, auch das neue Update hat nicht geholfen.

Jetzt heißt es auf das finale Herbst-Release zu warten oder den FB Support zu kontaktieren und in Zukunft auf Laborversionen zu verzichten, auch wenn das neue Design genial ist. Meine Liebe zu Fritzboxen ist nicht gebrochen!!!
 
Back
Top