henere
Goto Top

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

Content-Key: 395945

Url: https://administrator.de/contentid/395945

Ausgedruckt am: 28.03.2024 um 20:03 Uhr

Mitglied: aqui
aqui 17.12.2018 aktualisiert um 10:16:13 Uhr
Goto Top
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.. face-wink
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 face-wink
Noch viel besser, da sicherer wäre ein VPN Server in der Peripherie (Router, Firewall) gewesen !
Mitglied: Henere
Henere 17.12.2018 aktualisiert um 10:33:40 Uhr
Goto Top
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
Mitglied: Henere
Henere 17.12.2018 um 10:53:46 Uhr
Goto Top
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 ?
Mitglied: Henere
Henere 17.12.2018 um 18:44:25 Uhr
Goto Top
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 !
Mitglied: Henere
Henere 17.12.2018 um 20:55:47 Uhr
Goto Top
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
Mitglied: LordGurke
LordGurke 18.12.2018 aktualisiert um 11:02:57 Uhr
Goto Top
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.
Mitglied: Henere
Henere 18.12.2018 um 13:27:01 Uhr
Goto Top
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
Mitglied: aqui
aqui 18.12.2018 aktualisiert um 13:35:58 Uhr
Goto Top
und dann kommt ein CentOS drauf.
Endlich mal was Vernünftiges ! face-monkey Noch besser = Realisiere das VPN auf deinem Router oder Firewall !
Ich denke hier ist eine Neu-Inst schneller als die Fehlersuche.
Ganz sicher...
Mitglied: Henere
Henere 18.12.2018 um 14:08:56 Uhr
Goto Top
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
Mitglied: Henere
Henere 19.12.2018 um 02:15:09 Uhr
Goto Top
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
Mitglied: LordGurke
LordGurke 19.12.2018 um 11:14:54 Uhr
Goto Top
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.
Mitglied: aqui
aqui 19.12.2018 um 11:34:57 Uhr
Goto Top
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 ...