17.12.2018, aktualisiert um 20:45:29 Uhr

2469

OpenVPN - Routingprobleme

Moin zusammen,

hab einen OpenVPN auf Server 2016.
Seit Freitag hat ein Notebook Probleme irgendwas durch den Tunnel zu erreichen. Er baut die VPN-Verbindung auf, aber es gehen keine Pakete in den Tunnel.
Andere PCs, Clients funktionieren Problemlos.

Notebook W10 1803 - alle Patches installiert

Nach der Einwahl:

Ethernet-Adapter Ethernet:

   Verbindungsspezifisches DNS-Suffix: blabla.xyz
   Beschreibung. . . . . . . . . . . : TAP-Windows Adapter V9
   Physische Adresse . . . . . . . . : 00-FF-CB-D0-74-DD
   DHCP aktiviert. . . . . . . . . . : Ja
   Autokonfiguration aktiviert . . . : Ja
   IPv4-Adresse  . . . . . . . . . . : 10.10.10.6(Bevorzugt) 
   Subnetzmaske  . . . . . . . . . . : 255.255.255.252
   Lease erhalten. . . . . . . . . . : Montag, 17. Dezember 2018 09:43:42
   Lease l„uft ab. . . . . . . . . . : Dienstag, 17. Dezember 2019 09:43:42
   Standardgateway . . . . . . . . . : 
   DHCP-Server . . . . . . . . . . . : 10.10.10.5
   DNS-Server  . . . . . . . . . . . : 192.168.0.2
   NetBIOS ber TCP/IP . . . . . . . : Aktiviert

IPv4-Routentabelle
===========================================================================
Aktive Routen:
     Netzwerkziel    Netzwerkmaske          Gateway    Schnittstelle Metrik
          0.0.0.0          0.0.0.0      172.20.10.1      172.20.10.4     55
       10.10.10.1  255.255.255.255       10.10.10.5       10.10.10.6    291
       10.10.10.4  255.255.255.252   Auf Verbindung        10.10.10.6    291
       10.10.10.6  255.255.255.255   Auf Verbindung        10.10.10.6    291
       10.10.10.7  255.255.255.255   Auf Verbindung        10.10.10.6    291
        127.0.0.0        255.0.0.0   Auf Verbindung         127.0.0.1    331
        127.0.0.1  255.255.255.255   Auf Verbindung         127.0.0.1    331
  127.255.255.255  255.255.255.255   Auf Verbindung         127.0.0.1    331
      172.20.10.0  255.255.255.240   Auf Verbindung       172.20.10.4    311
      172.20.10.4  255.255.255.255   Auf Verbindung       172.20.10.4    311
     172.20.10.15  255.255.255.255   Auf Verbindung       172.20.10.4    311
      **192.168.0.0    255.255.255.0       10.10.10.5       10.10.10.6    291**
        224.0.0.0        240.0.0.0   Auf Verbindung         127.0.0.1    331
        224.0.0.0        240.0.0.0   Auf Verbindung       172.20.10.4    311
        224.0.0.0        240.0.0.0   Auf Verbindung        10.10.10.6    291
  255.255.255.255  255.255.255.255   Auf Verbindung         127.0.0.1    331
  255.255.255.255  255.255.255.255   Auf Verbindung       172.20.10.4    311
  255.255.255.255  255.255.255.255   Auf Verbindung        10.10.10.6    291

Aber:

tracert -d 192.168.0.2
Routenverfolgung zu 192.168.0.2 über maximal 30 Hops

  1     *        *        *     172.20.10.4
  2

Wieso wirft der die Pakete nicht (mehr) in den Tunnel ?
Drei andere Clients haben identische Konfiguration, damit funktioniert es einwandfrei.
Auf dem Notebook ist, wie aber auf den anderen Clients auch, Trendmicro WFBS mit identischer Konfiguration.

Grüße, Henere

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 395945

Url: https://administrator.de/forum/openvpn-routingprobleme-395945.html

Ausgedruckt am: 14.05.2025 um 05:05 Uhr

12 Kommentare

Neuester Kommentar

Er baut die VPN-Verbindung auf,

Wirklich ?? Erzählen fast alle hier... Vertrauen ist gut, Kontrolle ist besser.
Logauszug beim Dialin wäre wie immer hilfreicher hier als Schwüre..

aber es gehen keine Pakete in den Tunnel.

Von WO nach WO sollen denn Pakete gehen ?? Diese Aussage wäre auch hilfreich für eine zielführende Hilfe ??

Nur so viel...
Routing Tabelle stimmt und ist korrekt. Sagt auch das das VPN Dialin wohl dann auch mehr oder minder OK ist.
Windows ist hier wie immer (vermutlich) der böse Buhmann.
Die dümmliche Winblows Netzwerkerkennung hast du vermutlich nicht unter dem virtuellen Netzwerk Tunnel Interface (TAP) deaktiviert. Damit schlägt dann wegen des fehlenden Getways die Netzwerkerkennung fehl und die lokale Winblows Firewall "deklariert" dieses Netzwerk dann als öffentlich und blockt komplett inbound allen Traffic. Damit ist dann alles aus am VPN Interface.
Linux wäre die bessere Wahl gewesen

Noch viel besser, da sicherer wäre ein VPN Server in der Peripherie (Router, Firewall) gewesen !

Moin Aqui,

derzeit noch:
Notebook > Internet > Router mit PortForwarding UDP5000 -> OpenVPN-Server - internes Netz

Bis Donnerstag oder Freitag ging es noch Problemlos, es wird nur RDP darüber genutzt.
Netzwerkerkennung schliesse ich hier aus, da es nicht um Inbound, sondern outbound traffic geht.
Ich kann nichts, weder im 10.0.0.0er Transfernetz, noch den OpenVPN-Server anpingen. Jeglicher Traffic für 10.10.10.0 und 192.168.0.0 wird nicht in den Tunnel geworfen, sondern auf das WLAN-Interface, wo die Pakete dann verworfen werden.

Nehme ich die .ovpn Config vom Notebook auf meinen PC, so klappt das sofort.

Unterschied: Das Notebook hat über WLAN Tethering von einem Eierföhn Internet. Aber wenn Vodafone etwas blockeren würde, dann wäre der Tunnelaufbau doch gar nicht möglich ?
Und das dürfte ja auch die Routingtabelle nicht interessieren. Problem ist ja der Tracert (als Beispiel), der nicht in den Tunnel will.

Neu gestartet wurde das NB auch schon.

Grüße, Henere

Nachtrag:

Kann das damit etwas zu tun haben ?

ifconfig-pool-persist "C:\\Programme\\OpenVPN\\ipp.txt"  
NB-lalelu,10.10.10.4

Das NB bekommt ja die .6, warum steht in der ipp.txt dann die .4 ?

Servus,

also nach

netsh winsock reset
netsh int ip reset
ipconfig /release
ipconfig /renew
ipconfig /flushdns 

auf der betroffenen Büchse gefolgt von einem reboot tut das VPN nun wieder das was es tun soll.

Danke Bill !

Nein, das war es nicht. Es geht auf dem Laptop schon wieder nicht und auf einem PC, auf dem es heute mittag nachweislich noch ging (mein eigener) tritt jetzt das gleiche Problem auf.
Es wurden keine neuen Updates installiert. Weder auf dem Server noch auf den Clients.

Welche Logs wären denn interessant zu posten ?
Und auf welchem Debug-Level ?

Henere

Hast du auf dem Client mal einen Traceroute gemacht um zu sehen, wo die Pakete versanden resp. ob sie überhaupt durch das VPN geroutet werden?

Nachtrag: War wohl zu spät, sorry, habe deinen Traceroute völlig übersehen...

Hast du den OpenVPN-Client denn explizit als Administrator gestartet?
Wenn nicht, fehlen die Berechtigungen zum Anlegen der Routen und dann wird natürlich auch nichts in den Tunnel geroutet.

Moin Lordgurke,

das ist mit der aktuellen Version nicht mehr nötig. Das geht auch wenn ein Ottonormal-Nutzer am Rechner angemeldet ist. Siehe Routingtable. Die ist von einem Ottonormalnutzer.
Es ging ja auch mehrere Wochen.
Da mittlerweile auch mein PC und eine dritte Station nicht mehr ins VPN kommen, schiebe ich die Schuld jetzt auf den Server, allerdings wurden an diesem keine Veränderungen vorgenommen.

Naja, das war ein Versuch auf Server2016. Ich mach den jetzt platt und dann kommt ein CentOS drauf. Ich denke hier ist eine Neu-Inst schneller als die Fehlersuche.

Danke und Grüße,

Henere

und dann kommt ein CentOS drauf.

Endlich mal was Vernünftiges !

Noch besser = Realisiere das VPN auf deinem Router oder Firewall !

Ich denke hier ist eine Neu-Inst schneller als die Fehlersuche.

Ganz sicher...

Hi Aqui,

ich habe bewusst ein Blech genommen, die Drecks-Zychsel-Firewall bringt ja keine VPN-Leistung. In meinen äteren Threads nachzulesen.
Darüber bin ich schon lange weg.
Evtl kommt mal ne PFSense hin. Aber .... Zeit, Geld, Winter.... alles nette Ausreden um es zu verschieben, ich weis.

Grüße, Henere

Sodele,

der Umzug auf CentOS ist vollbracht. Zwar mit einigen Tücken, aber nun geht es wieder.
Ich habe 2 x CentOS hergenommen.
1x OpenVPN
1x Lets Encrypt Zert-Server

Damit ich auf dem OpenVPN keinen Apachen offen herumstehen lassen muss, kommt eine 2te VM mit CentOS zum Laufen. Diese öffnet zum Update der Lets Encrypt-Zertifikate kurz den Port 80, danach macht iptables den Port wieder dicht. Die Keys werden dann per SSH in der DMZ kopiert und auf Validität geprüft bevor openvpnserver neu gestartet wird..
Eine Angriffsfläche weniger.
Um Scriptkiddies abzuhalten, wird mit TA.keys gearbeiet.Userbasiert werden Routen gepushed, damit gewisse User nur gewisse Server erreichen. Zusätzlich schaut IPTables danach, wer wohin darf.

Ziel erreicht, auch wenn es ein Kampf mit viel Google war.
Wenn ich Lust und Zeit habe, schreibe ich eine Anleitung dazu.

Henere

Das klingt nach unnötigem Aufwand, zumindest was den Letsencrypt-Teil angeht...
Da das Zertifikat des Servers ohnehin statisch an die Clients verteilt wird und die dagegen prüfen ist es eigentlich überhaupt nicht notwendig, ein Zertifikat zu haben welches von einer vertrauenswürdigen CA signiert wurde.
Realistisch betrachtet ist es sogar ein Sicherheitsrisiko, weil der Client jetzt entweder alle drei Monate mit dem neuen Server-Zertifikat versorgt werden müsste — oder er vertraut der CA komplett, was Angriffsmöglichkeiten per MITM ermöglicht.

Dto. Der Aufwand ist eigentlich unnötig und kontraproduktiv. Jedenfalls was die VPN Keys anbetrifft.
Für LetsEncrypt hätte auch ein simpler Cerbot Cronjob gereicht.
Siehe hier Kapitel 4.2.1
https://bayton.org/docs/nextcloud/installing-nextcloud-on-ubuntu-16-04-l ...

Frage Netzwerke Router, Routing

Mehr von Henere

TrendNet Webcam - Probleme beim einrichtenHenere - 6 Kommentare

Webcam Empfehlung gesuchtHenere - 5 Kommentare

WSUS - Updates werden nicht geladenHenere - 8 Kommentare

ToolGetExchangeStatusForWatcher.exeHenere - 12 Kommentare

Heiß diskutiert