Keine Internetverbindung mit OpenVPN Client

[lhinny]

Hallo, folgendes Setup:

Ich habe eine Windows 10 Kiste mit OpenVPN drauf und ein Android Gerät mit der OpenVPN für Android App.
Die Verbindung zwischen beiden funktioniert schon mal, auch über das Internet. Ich kann mich also Mit dem Handy zum VPN Server verbinden. Mein Problem: Das Handy ist mit dem VPN Server verbunden, eine Kommunikation mit dem Internet ist aber in der Zeit nicht mehr möglich, ich kann also keine Internet-Seiten öffnen. Hat jemand eine Idee was falsch sein könnte bzw. fehlt?



Die Server-Config sieht so aus:

local 192.168.0.190
port 1194
proto udp
dev tun

dh "C:\\Programme\\OpenVPN\\server-keys\\dh4096.pem"
ca "C:\\Programme\\OpenVPN\\server-keys\\ca.crt"
cert "C:\\Programme\\OpenVPN\\server-keys\\Server01.crt"
key "C:\\Programme\\OpenVPN\\server-keys\\Server01.key"

server 10.19.15.0 255.255.255.0
ifconfig-pool-persist "C:\\Programme\\OpenVPN\\ipp.txt"
client-to-client

client-config-dir "C:\\Programme\\OpenVPN\\ccd"
push "route 192.168.0.0 255.255.255.0"
push "dhcp-option DNS 192.168.0.1"

keepalive 10 120
comp-lzo
persist-key
persist-tun

status "C:\\Programme\\OpenVPN\\log\\openvpn-status.log"
log "C:\\Programme\\OpenVPN\\log\\openvpn.log"
log-append "C:\\Programme\\OpenVPN\\log\\openvpn.log"
verb 3

Die Client-Config sieht so aus:

client
dev tun

proto udp
remote XXX.XXX.XXX.XXX 1194
resolv-retry infinite
nobind
persist-key
persist-tun

ca "C:\\Program Files\\OpenVPN\\config\\ca.crt"
cert "C:\\Program Files\\OpenVPN\\config\\Client01.crt"
key "C:\\Program Files\\OpenVPN\\config\\Client01.key"

comp-lzo
verb 3

 

[Nilson]

Es gibt einen Bug unter Linux/Andriod, wenn du einen DNS pushst. Dann geht die DNS Auflösung nicht mehr. Leider hab ich bisher für kein (verlässlichen) Workaround gefunden.

 

[lhinny]

@Nilson
Hmm, danke für den Hinweis. Wenn ich den Eintrag "push "dhcp-option DNS 192.168.0.1"" entferne geht das Internet auf dem Handy aber eben nicht über VPN

 

[Mr. Robot]

Ich hab bislang noch keinen OpenVPN-Server aufgesetzt, und dementsprechend wenig Ahnung von. Aber ich antworte trotzdem mal...

So wie ich das sehe, bekommt der Client mit dem 'push "route 192.168.0.0 255.255.255.0"' die Adresse für dein LAN.
Er sollte also schon mal auf die Rechner in deinem lokalen Netzwerk zugreifen können.

Ins Internet kommt er damit nicht. Wie denn auch? Er kennt das Default-Gateway (also die Adresse vom Router) von deinem Netzwerk gar nicht. (Da hilft auch kein DNS-Eintrag.)


Evtl. hilft das hier aus den sample-config-files:

# If enabled, this directive will configure
# all clients to redirect their default
# network gateway through the VPN, causing
# all IP traffic such as web browsing and
# and DNS lookups to go through the VPN
# (The OpenVPN server machine may need to NAT
# or bridge the TUN/TAP interface to the internet
# in order for this to work properly).

push "redirect-gateway def1 bypass-dhcp"

Aber wie gesagt, ich hab das noch nie gemacht. Ich rate nur etwas rum.

 

[lhinny]

Habs grad noch mal getestet, irgendwie ist doch noch mehr im Argen. Ich kann nicht mal die Rechner im Netzwerk pingen.

 

[Raijin]

Grundsätzlich muss man am Client natürlich das Standard-Gateway auf den VPN-Server setzen, sonst routet der Client trotz VPN munter weiter Richtung Internet-Router und eben nicht Richtung VPN. Dazu dient wie von Mr. Robot schon gepostet die Option "redirect-gateway". Ob man das von der server.conf über push zum Client schickt oder direkt in der client.conf (ohne push) eingibt, ist im Prinzip egal.

Darüberhinaus muss der VPN-Server nun den über ihn gerouteten Traffic natürlich auch korrekt weiterleiten. Dazu braucht muss zum einen "IP-Forwarding" aktiviert werden und zum anderen muss auch der Rückweg vom Internet zum VPN gewährleistet sein. Entweder man bringt dem VPN-Server NAT bei (@Windows: netsh routing ip nat ...) oder aber man fügt im Internet-Router eine Route ins VPN-Subnetz hinzu (zB 10.15.19.0/24 via 192.168.0.123).


Wenn man keine Geräte im LAN über das VPN pingen kann, dann wird der besagte Rückweg das Problem sein. Selbst wenn der Ping vom Client durch das VPN geht, kommt er dort mit der Absender-IP 10.15.19.x an. Macht der VPN-Server nun kein NAT, ersetzt also besagte Absender-IP durch seine eigene LAN-IP, dann bekommt das Ziel-Gerät einen Ping mit unbekanntem Absender und leitet die Antwort Richtung Standard-Gateway, den lokalen Internet-Router. Wenn dieser nix vom VPN-Subnetz weiß (siehe Route weiter oben), dann schickt er die Antwort über die Internetleitung und dort gibt's keine Antwort.

 

[lhinny]

Danke Raijin,

ich google mal sobald ich zuhause bin bezüglich "netsh routing ip nat" und gucke ob ich das irgendwie gelöst bekomme.

Ergänzung (1. November 2017)

IP-Forwarding hab ich jetzt in Windows aktiviert, zumindest diesen Dienst. Und im Router folgendes eingestellt:


Pingen geht leider immer noch nicht. Die Rechner sehen sich einfach nicht
Wo ist mein Denkfehler oder was fehlt noch?

Ergänzung (1. November 2017)

Okay, hab meinen Denkfehler gefunden. Ich sollte natürlich den VPN als Gateway eintragen. Ich hab jetzt aus 192.168.0.1 für 10.19.15.0 die 192.168.0.190 gemacht und jetzt läufts. Handy ist über 4G auf dem VPN und wenn ich die IP checke, wird mir meine IP vom Festnetz angezeigt. Vielen Dank für deine Hilfe! Damit kann der Urlaub und das sichere Surfen in offenen WLANs kommen

Lösung
Für den Fall das mal jemand auf den Thread hier stößt und das gleiche Problem hat, hier nun die fertige Konfiguration die bei mir funktioniert:

Server-Config

local 192.168.0.190
port 1194
proto udp
dev tun

dh "C:\\Programme\\OpenVPN\\server-keys\\dh4096.pem"
ca "C:\\Programme\\OpenVPN\\server-keys\\ca.crt"
cert "C:\\Programme\\OpenVPN\\server-keys\\Server01.crt"
key "C:\\Programme\\OpenVPN\\server-keys\\Server01.key"

server 10.19.15.0 255.255.255.0
ifconfig-pool-persist "C:\\Programme\\OpenVPN\\ipp.txt"
client-to-client

client-config-dir "C:\\Programme\\OpenVPN\\ccd"
push "route 192.168.0.0 255.255.255.0"
push "dhcp-option DNS 192.168.0.1"
push "redirect-gateway def1 bypass-dhcp"

keepalive 10 120
comp-lzo
persist-key
persist-tun

status "C:\\Programme\\OpenVPN\\log\\openvpn-status.log"
log "C:\\Programme\\OpenVPN\\log\\openvpn.log"
log-append "C:\\Programme\\OpenVPN\\log\\openvpn.log"
verb 3

Client-Config

client
dev tun

proto udp
remote XXX.XXX.XXX.XXX 1194
resolv-retry infinite
nobind
persist-key
persist-tun

ca "C:\\Program Files\\OpenVPN\\config\\ca.crt"
cert "C:\\Program Files\\OpenVPN\\config\\Client01.crt"
key "C:\\Program Files\\OpenVPN\\config\\Client01.key"

comp-lzo
verb 3

Router-Config

Und natürlich die entsprechende Port-Weiterleitung von Port 1194 an 192.168.0.190.

 

[Raijin]

Na wunderbar, so soll's sein

Viel Spaß damit!



Kleiner Tipp noch: Sollte außer ping auch mal ein anderer Dienst auf einem PC nicht via VPN erreichbar sein, check mal die Firewall. In der erweiterten Ansicht wo man die Regeln sieht muss man bei der jeweiligen Regel für den Dienst auch etwaige "fremde" Absende-IPs bzw -Subnetze freigeben. Dazu die Regel mit Doppelklick öffnen und im Reiter "Scope" (deutsche Bezeichnung anders) unter Quelle das VPN-Subnetz hinzufügen oder gar auf All IP umschalten.

 

[lhinny]

Hmm, von jetzt auf gleich geht das nicht mehr, obwohl ich nichts geändert hab. Ich kann mich zwar zum Server verbinden, Zugriff aufs Internet gibts aber keinen mehr :/

 

[Raijin]

Check mal das Routing:

Start --> cmd
--> tracert 8.8.8.8

Da sollte als 1. Hop dein OpenVPN-Server kommen, als zweiter der dortige Internet-Router und anschließend das www. Sollte schon der erste Hop nicht stimmen, dann geht der Traffic gar nicht erst ins VPN rein, sprich die Routing-Tabelle ist nicht korrekt. Ist allerdings erst der 2. Hop fehlerhaft bzw. nicht vorhanden, dann leitet der VPN-Server nicht korrekt weiter.


OpenVPN ändert normalerweise nicht direkt das Standardgateway, sondern fügt zwei höherwertige Routen hinzu, die das Standard-Gateway gewissermaßen aushebeln. Das sind zwei Routen, die als Subnetzmaske 128.0.0.0 haben und zum VPN-Server leiten. Die Routing-Tabelle siehst du mit "route print"

 

[lhinny]

Problem Gelöst... der Routing und RAS Dienst ist abgeschmiert^^

 

[ekeis]

Hallo zusammen,

darf ich dieses Thema nochmal aufwärmen? Eine Nachfrage habe ich noch:

• Gibt es eine Möglichkeit, die server.conf so zu konfigurieren, dass die Einstellungen, die der Client beim Hochfahren des PCs vom DHCP-Server aus dem lokalen LAN bekommen hat, nicht geändert werden?

Oder andersherum:

• Ich möchte, dass der Client seine lokale Namesauflösung behält und dass der Internetverkehr nicht über der per OpenVPN angebundene Netzwerk läuft.
• OpenVPN sollt nur dazu genutzt werden, per IP-Adresse verschlüsselt auf das entfernte Netzwerk zuzugreifen. Alles andere (Internetverkehr, Namensauflösung etc.) soll so funktionieren wie vor dem Aufbau der OpenVPN-Verbindung.
• Ich möchte die server.conf anpassen, so dass diese Funktionalität zentral gilt.
• Ich möchte vermeiden, für jeden Client, die automatisch erzeugte client.ovpn separat editieren.

Ich wäre dankbar für entsprechende Hinweise auf Doku oder Posts.

Danke Euch.

Viele Geüße
Oliver

 

[Raijin]

Wenn es darum geht ob Internetverkehr und/oder Netzwerkverkehr durch das VPN geht oder nicht, muss das Routing angepasst werden.

Folgende Beispielkommandos beeinflussen das Routing

push "route 192.168.0.0 255.255.255.0"
push "redirect-gateway def1 bypass-dhcp"

push "route.." in der server.conf weist dem Client bei der Verbindung eine neue Route zu. Im Beispiel würde der Client also eine Route in das 192.168.0.0/24 Subnetz in seine Routing-Tabelle eintragen. Da in der server.conf kein Gateway in der Route steht, wird implizit die IP des VPN-Servers genommen. Der Client wird während der VPN-Verbindung also alle IP-Adressen mit 192.168.0.x über das VPN schicken (zB weil das das LAN hinter dem Server ist).

push "redirect-gateway.." in der server.conf weist dem Client bei der Verbindung ein neues Standard-Gateway zu. Das heißt, dass der Client während der VPN-Verbindung alles über das VPN schickt, was er nicht lokal erreichen kann bzw. wo keine andere Route in seiner Routing-Tabelle greift. Das ist also quasi die über-VPN-surfen-Einstellung. Einfach weglassen und das Standard-Gateway des Clients bleibt unangetastet, der Client wird also nach wie vor seine normale Internetverbindung nutzen und nur das VPN-Subnetz selbst bzw. etwaige Subnetze in oben beschriebenen push "route.." Anweisungen über das VPN schicken.

push "dhcp-option DNS.." in der server.conf weist den Client an, den angegebenen DNS Server zur Namensauflösung zu nutzen. Soll der Client weiterhin den lokalen DNS (meistens der lokale Internet-Router) nutzen, lässt man diese Option weg. Allerdings können dann Geräte im VPN bzw. hinter dem VPN nur über IP-Adressen angesprochen werden, sofern der lokale DNS nicht explizit entsprechende Einträge beinhaltet.

Ausgehend von der Beispielkonfiguration in Beitrag #7 müsstest du also lediglich die letzten beiden erwähnten Optionen entfernen (redirect+dhcp-option). Die client-config-dir Anweisung benötigst du nur, wenn du client-spezifische Einstellungen machen willst, die dann eben nicht in einer indiviuellen client.conf stehen müssen - die ja nicht erwünscht ist -, sondern je nach Client individuell vom Server zum Client gepusht werden. So könnte zum Beispiel der Client "Herbert" eben doch als Ausnahme push "redirect-gateway.." bekommen, während alle anderen Clients ihr altes Gateway beibehalten.