OPENVPN: Notebook über Hotspot ins VPN und dann ins LAN & Internet funktioniert nicht

[chrizz9988]

OPENVPN: Notebook über Hotspot ins VPN und dann ins LAN & Internet funktioniert nicht

Hallo zusammen,
ich habe folgende Problematik:
- Ein Notebook (Windows 7) erhält seine Internetverbindung über die Hotspotfunktion eines Smartphones
- Mit Hilfe dieser Internetverbindung wird eine VPN-Verbindung (OpenVPN) zu einem VPN-Server (Debian Wheezy) hergestellt (funktioniert so weit)
- Der restliche Netzwerktraffic (Internet & Zugriff auf andere Geräte im LAN des VPN-Servers) soll über eben jenes VPN erfolgen
==> das funktioniert nicht.

Hier ersteinmal eine Grafik des Netzwerks


Im Router 192.168.1.1 ist die statische Route zum VPN-Server drin.


Nun die Client-Seite (das Notebook)
Bei verbundenem VPN sieht ipconfig /all wie folgt aus:


Hier frage ich mich schon wieso das Standardgateway bei TAP-Windows Adapter V9 fehlt. Das könnte schon die Ursache sein?! Wieso steht da nicht der 192.168.2.1 drin?

Route print sieht wie folgt aus:


==> Hier sollte bei 0.0.0.0 doch auch der 192.168.2.1 drin stehen und nicht der 192.168.43.1, oder?

Pings funktionieren wie folgt (oder auch nicht):
ping 192.168.2.6 (VPN-Adapter von sich selbst) ==> erfolgreich
ping 192.168.2.1 (tun0 des VPN-Servers) ==> erfolgreich
ping 192.168.1.1 (Router im LAN des VPN-Servers) ==> nicht erfolgreich
ping 192.168.2.5 (DHCP v. TAP-Windows Adapter V9) ==> nicht erfolgreich

Jetzt die Serverseite
Server.conf sieht wie folgt aus

port 1194
proto udp
dev tun
ca /etc/openvpn/easy-rsa2/keys/meineca.crt
cert /etc/openvpn/easy-rsa2/keys/meinedyndnsadresse.crt
key /etc/openvpn/easy-rsa2/keys/meinedyndnsadresse.key # This file should be kept secret
dh /etc/openvpn/easy-rsa2/keys/dh1024.pem
server 192.168.2.0 255.255.255.0
ifconfig-pool-persist ipp.txt
push "route 192.168.1.0 255.255.255.0"
push "redirect-gateway def1 bypass-dhcp"
keepalive 10 120
comp-lzo
user nobody
group nogroup
persist-key
persist-tun
status openvpn-status.log
verb 3

ping 192.168.2.1 (tun0 von sich selbst) ==> erfolgreich
ping 192.168.1.1 (router im LAN) ==> erfolgreich
ping 192.168.2.6 (Notebook im VPN) ==> nicht erfolgreich (kann aber auch die Windows-Firewall blocken?)

in /proc/sys/net/ipv4/ip_forward steht mittlerweile auch "1" (ohne Hochkomma) drin. Dachte erst es liegt daran, brachte aber keine Besserung.

Frage
Habt ihr eine Idee wieso ich zum Einen nicht mit dem Notebook über das VPN im Internet surfen kann und außerdem keine Geräte im Subnetz 192.168.1.0 / 24 anpingen kann?

Danke im Voraus!!!!

 

[fdsonne]

mach mal nen Ping auf die 192.168.1.104 vom Notebook aus, welches eine aktive VPN Verbindung hat. Geht das?
Auch interessant wäre, wenn du mal ein traceroute auf eine IP aus dem 192.168.1.0/24er Netz machst... Wo bleibt der hängen?
Ich würde einfach mal ins blaue raten und behaupten, das dein VPN Server die Daten nicht weiter schickt. Sprich du wirst am VPN Server hängen bleiben...

Was das Thema INet Zugriff vom Notebook über UMTS bei aktiver VPN Verbindung angeht. Keine Ahnung, wie man das bei OpenVPN konfigurieren muss, aber mich dünkt, das hat was mit split tunneling zu tun. Das Notebook wird jeglichen Traffic wohl über die VPN Verbindung schicken. -> dort gehts natürlich nicht weiter, weil die 192.168.1.1 nicht erreichbar ist, wie dein Ping ja aussagt, entsprechend auch kein INet Zugriff. Mit split tunneling wird nur der Traffic ins "VPN" geleitet, welcher auch definiert ist. Der Rest geht am VPN vorbei, direkt ins INet (über UMTS) -> ist halt eine Frage der Sicherheit, ob ma das will oder nicht.

Thema Routingtabelle. Der virtuelle VPN Adapter auf deinem Notebook legt ein mini Netz an. (siehst du an der Maske 255.255.255.252). Das Netz fasst nur vier Adressen. Die eigene + ein "Gateway". Was dann in der Konstellation idR die nachfolgende oder vorrangehende deiner eigenen ist. Hast du also die 192.168.2.6 ist das "Gateway" eben die 2.5. Netz/Broadcast Adresse ist jeweils eine davor/dahinter... Das ist auch völlig in Ordnung so. Einen default Gateway Eintrag brauch es nicht zwingend. Eine Route ist "ausreichend"... Es ist sogar eher von Nachteil, einen zweiten default Gateway Eintrag zu setzen. Besser so wie es der virtuelle VPN Adapter anlegt. -> zwei "näher" spezifizierte Routen. Einmal die "0.0.0.0 128.0.0.0 gateway 192.168.2.5 metric 30" und einmal die "128.0.0.0 128.0.0.0 gateway 192.168.2.5 metric 30". Damit erschlägst du quasi alles. Und es ist eben näher spezifiziert als die eigentliche default Route 0.0.0.0/0. Egal was du also vom Notebook aus ansprichst, es greift nicht die default Route, sondern eine der beiden näher spezifizierten Routen. -> ergo jeglicher Traffic geht durch den Tunnel!



PS: was mir noch einfällt, was hast du für nen Router da stehen?
Bei vielen Consumer Modelle kann man statische Routen schlicht und ergreifend nur auf der public Seite setzen... Sprich es könnte einfach sogar sein, das dein Eintrag da gar nicht greift.
Das bekommst du weg, wenn du einfach mal wahlweise auf einem Gerät im Netz 192.168.1.0/24 (nicht den Router! und nicht den VPN Server) einen statischen Eintrag analog dem von dir geposteten einsetzt. Und dann mal versuchst von deinem Notebook über den Tunnel dieses Gerät zu pingen.

EDIT: eventuelle Firewall Geschichten solltest du freilich aber auch temporär ausknipsen (du sprachst ja was von Windows Firewall)
Das ist für derartige troubleshooting Tests eher hinderlich...

 

[chrizz9988]

Hi und Danke für die schnelle Antwort !

mach mal nen Ping auf die 192.168.1.104 vom Notebook aus, welches eine aktive VPN Verbindung hat. Geht das?

Überraschender Weise geht das!

Auch interessant wäre, wenn du mal ein traceroute auf eine IP aus dem 192.168.1.0/24er Netz machst... Wo bleibt der hängen?

Habe zunächst mal auf die 192.168.1.104 ein traceroute gemacht.

tracert 192.168.1.104

Routenverfolgung zu 192.168.1.104 über maximal 30 Abschnitte
1 97 ms 98 ms 108 ms 192.168.1.104

Ist das normal, dass er den anderen Adapter (192.168.2.1) nicht anzeigt?

Nun ein traceroute auf den Router und das ist wieder merkwürdig:

tracert 192.168.1.1

Routenverfolgung zu 192.168.1.1 über maximal 30 Abschnitte
1 * * * Zeitüberschreitung der Anforderung.
2 * * * Zeitüberschreitung der Anforderung.
3 * * * Zeitüberschreitung der Anforderung.
4 * * * Zeitüberschreitung der Anforderung.
5 * * * Zeitüberschreitung der Anforderung.

Hä? Wieso findet er nicht wenigstens 192.168.1.104?

Was das Thema INet Zugriff vom Notebook über UMTS bei aktiver VPN Verbindung angeht. Keine Ahnung, wie man das bei OpenVPN konfigurieren muss, aber mich dünkt, das hat was mit split tunneling zu tun. Das Notebook wird jeglichen Traffic wohl über die VPN Verbindung schicken. -> dort gehts natürlich nicht weiter, weil die 192.168.1.1 nicht erreichbar ist, wie dein Ping ja aussagt, entsprechend auch kein INet Zugriff. Mit split tunneling wird nur der Traffic ins "VPN" geleitet, welcher auch definiert ist. Der Rest geht am VPN vorbei, direkt ins INet (über UMTS) -> ist halt eine Frage der Sicherheit, ob ma das will oder nicht.

Hier habe ich mich wohl seltsam ausgedrückt. Ich möchte es genau so, wie du es sagst (fett markiert): ALLES soll über das VPN.

Thema Routingtabelle. Der virtuelle VPN Adapter auf deinem Notebook legt ein mini Netz an. (siehst du an der Maske 255.255.255.252). Das Netz fasst nur vier Adressen. Die eigene + ein "Gateway". Was dann in der Konstellation idR die nachfolgende oder vorrangehende deiner eigenen ist. Hast du also die 192.168.2.6 ist das "Gateway" eben die 2.5. Netz/Broadcast Adresse ist jeweils eine davor/dahinter... Das ist auch völlig in Ordnung so. Einen default Gateway Eintrag brauch es nicht zwingend. Eine Route ist "ausreichend"... Es ist sogar eher von Nachteil, einen zweiten default Gateway Eintrag zu setzen. Besser so wie es der virtuelle VPN Adapter anlegt. -> zwei "näher" spezifizierte Routen. Einmal die "0.0.0.0 128.0.0.0 gateway 192.168.2.5 metric 30" und einmal die "128.0.0.0 128.0.0.0 gateway 192.168.2.5 metric 30". Damit erschlägst du quasi alles. Und es ist eben näher spezifiziert als die eigentliche default Route 0.0.0.0/0. Egal was du also vom Notebook aus ansprichst, es greift nicht die default Route, sondern eine der beiden näher spezifizierten Routen. -> ergo jeglicher Traffic geht durch den Tunnel!

Danke für die Erklärung! Die Quintessenz ist nun klar - alles geht durch den Tunnel ! Nur zum Verständnis: Der VPN-Server ist ja mit seiner IP 192.168.2.1 in einem anderen Subnetz, als ich mit 192.168.2.6, aber das macht dann wohl die VPN-Software und schlüsselt das um? Ich kann z.B. auf dem VPN-Server die 192.168.2.5 nicht anpingen...ist wohl nur virtuell?

PS: was mir noch einfällt, was hast du für nen Router da stehen?
Bei vielen Consumer Modelle kann man statische Routen schlicht und ergreifend nur auf der public Seite setzen... Sprich es könnte einfach sogar sein, das dein Eintrag da gar nicht greift.

TP-Link TL-WR1043ND

Das bekommst du weg, wenn du einfach mal wahlweise auf einem Gerät im Netz 192.168.1.0/24 (nicht den Router! und nicht den VPN Server) einen statischen Eintrag analog dem von dir geposteten einsetzt. Und dann mal versuchst von deinem Notebook über den Tunnel dieses Gerät zu pingen.

Das habe ich nicht machen können (mir gehen langsam die Geräte aus, sind nur noch Android-Geräte im Netz). ABER: Du hast mich auf die Idee gebracht, einfach mal von einem weiteren Mobilgerät im 192.168.1.0/24 Netz die 192.168.2.1 anzupingen.

Ping 192.168.2.1
==> erfolgreich

Ping 192.168.2.6
from 192.168.1.1 Redirect Host (New nexthop: 192.168.104) <-- immerhin, der "Beweis" das die statische Route klappt
==> leider trotzdem fehlgeschlagen

eventuelle Firewall Geschichten solltest du freilich aber auch temporär ausknipsen (du sprachst ja was von Windows Firewall)
Das ist für derartige troubleshooting Tests eher hinderlich...

Habe ich getan und siehe da: Vom VPN-Server aus klappt nun auch der Ping auf 192.168.2.6

Zusammenfassung
Was funktioniert
Ich kann nun also vom VPN-Server das Notebook im VPN anpingen (192.168.2.6).
Ich kann vom Notebook im VPN den VPN-Server (192.168.2.1) anpingen.
Ich kann vom Notebook im VPN auch den anderen Adapter des VPN-Servers für das LAN anpingen (192.168.1.104).
Ich kann vom VPN-Server auch den Router im LAN (192.168.1.1) anpingen.
Ich kann vom LAN (192.168.1.0 / 24) den Tunneladapter des Servers (192.168.2.1) anpingen.

Was nicht funktioniert
Wenn ich Traceroute 192.168.1.1 vom Notebook im VPN mache, dann kommt er seltsamer Weise nicht mal zum 192.168.2.1
Ich kann vom LAN (192.168.1.0 / 24) nicht das Notebook im VPN (192.168.2.6) anpingen.
Ich kann vom Notebook im VPN nicht ein anderes Gerät im LAN (bspw. 192.168.1.101) anpingen.

==> Irgendwie bleibt alles im VPN-Server hängen. Muss ich noch was mit iptables machen? Dort habe ich nix(!) gemacht.

Danke nochmal für die Hilfe und ich denke wir sind einen Schritt näher gekommen

 

[fdsonne]

Ist das normal, dass er den anderen Adapter (192.168.2.1) nicht anzeigt?

ja... Das ist durchaus normal. Da die 2.1 und die 1.104 ja das gleiche Gerät ist. Sprich du erreichst das Ziel wenn du so willst direkt ohne Umwege. Nimmt man es genau, wäre sogar die 2.5 (also der Gateway Eintrag deiner Routing Table am Notebook die gleiche "Kiste") Letztere ist halt nur virtuell.

tracert 192.168.1.1

Routenverfolgung zu 192.168.1.1 über maximal 30 Abschnitte
1 * * * Zeitüberschreitung der Anforderung.
2 * * * Zeitüberschreitung der Anforderung.
3 * * * Zeitüberschreitung der Anforderung.
4 * * * Zeitüberschreitung der Anforderung.
5 * * * Zeitüberschreitung der Anforderung.

Hä? Wieso findet er nicht wenigstens 192.168.1.104?

Hier liegt vermutlich ein Firewall Problem vor... Zum einen ist es durchaus legitim, das Router/VPN Gateways nicht auf ICMP antworten. Zum anderen könnte dir da noch die Firewall auf dem VPN Server dazwischen funken.

Hier habe ich mich wohl seltsam ausgedrückt. Ich möchte es genau so, wie du es sagst (fett markiert): ALLES soll über das VPN.

Dann ist zumindest die Config da erstmal soweit schick...

Das habe ich nicht machen können (mir gehen langsam die Geräte aus, sind nur noch Android-Geräte im Netz). ABER: Du hast mich auf die Idee gebracht, einfach mal von einem weiteren Mobilgerät im 192.168.1.0/24 Netz die 192.168.2.1 anzupingen.

Dann geht zumindest erstmal die Route auf deinem TP-Link Router. Kannst ja nochmal ein Traceroute machen auf die 2.1 um das genau zu verifizieren. Da sollte dann die 1.1 als erster und einziger Hop verzeichnet sein. -> danach kommt dann das Ziel.

==> Irgendwie bleibt alles im VPN-Server hängen. Muss ich noch was mit iptables machen? Dort habe ich nix(!) gemacht.

Das würde ich dann als nächstes mal anschauen. Wenn dir die Firewall des VPN Servers den Traffic wegblockt, gehts natürlich nicht weiter.
Dazu mal auf dem VPN Server ein "iptables -L" ausführen. Dann solltest du die Rules sehen. Ich kann dir aber aus dem Hut nicht sagen was da default ist und was da OpenVPN ggf. schon einträgt. Nach den derzeitigen Erkenntnissen scheint aber der VPN Server (wie oben schon vermutet) den Traffic zu blocken. Firewall liegt also nahe... Da der Ping vom Notebook über VPN auf die 1.104 schonmal geht, geht auch das Routing offenbar.

 

[chrizz9988]

Hallo!

Dann geht zumindest erstmal die Route auf deinem TP-Link Router. Kannst ja nochmal ein Traceroute machen auf die 2.1 um das genau zu verifizieren. Da sollte dann die 1.1 als erster und einziger Hop verzeichnet sein. -> danach kommt dann das Ziel.

==> jupp, so ist es!

Dazu mal auf dem VPN Server ein "iptables -L" ausführen. Dann solltest du die Rules sehen. Ich kann dir aber aus dem Hut nicht sagen was da default ist und was da OpenVPN ggf. schon einträgt.

Die Datei ist - bis auf die Überschriften für die 3 Kategorien INPUT, FORWARD & OUTPUT - leer.

Nach den derzeitigen Erkenntnissen scheint aber der VPN Server (wie oben schon vermutet) den Traffic zu blocken. Firewall liegt also nahe...

Ich weiß nun fast nicht mehr weiter...eines ist mir noch aufgefallen: Die Routing-Tabelle des VPN-Servers haben wir uns noch nicht genauer angesehen:


Das sah für mich seltsam aus, da das was in das 192.168.1.0/24 Netz soll, als Router * eingetragen hat. Was bedeutet *? Ich habe daher zur Sicherheit mal eine Route hinzugefügt.

route add -net 192.168.1.0 netmask 255.255.255.0 gw 192.168.1.1

Das hat aber auch nichts gebracht. Ich weiß nun nicht mehr weiter...

 

[fdsonne]

Die Datei ist - bis auf die Überschriften für die 3 Kategorien INPUT, FORWARD & OUTPUT - leer.

hier liegt warscheinlich der Hund begraben, denn wenn die Firewall per default eine deny all Regel anwendet, (die dann nichtmal irgendwo auftauchen muss), kommt auch kein Traffic durch.
Dazu am besten einfach mal nach iptables im INet suchen. Genaue Syntax der Befehle hab ich leider nicht im Kopf. Willst du es einfacher haben, gibt es bestimmt auch ne GUI um das zu konfigurieren. Irgendwie als Schlagwörter: "iptables add rule" oder sowas...
Als Hintergrund, du benötigst einfach eine (oder mehrere) Regeln, die dir den Traffic explizit erlauben. Sprich von Source(netz) zu Destination(Netz) mit dem und dem Service "access allow". Ggf. kann man sogar das ganze noch auf Interfaces einschränken/eingrenzen.
Also Source = 192.168.2.0/24, Destination 192.168.1.0/24, Service any, access allow... -> bedeutet dann schlicht und einfach, jede IP aus dem 2.0er Netz (dein VPN) darf zu jeder IP im 1.0er Netz (dein lokales Netz) über jeden Service (tcp, udp usf.) kommunizieren. Zumindest für den Funktionstest würde das reichen. Im Nachgang könnte man das ganze dann weiter eingrenzen. Sprich nur auf bestimmte Services als HTTP = TCP Port 80 oder HTTPS = TCP Port 443 usw. eingrenzen. Oder auch auf bestimmte Destinations gewisse Sachen explizit verbieten oder speziell erlauben. -> Ist dann einfach die Frage, wer da genau mit wem kommunizieren können soll.

Das sah für mich seltsam aus, da das was in das 192.168.1.0/24 Netz soll, als Router * eingetragen hat. Was bedeutet *? Ich habe daher zur Sicherheit mal eine Route hinzugefügt.

Die Route kann wieder raus, da sie sozusagen quatsch ist. Da der Server ein Bein im 192.168.1.0/24er Netz hat, braucht er auch keine Route um dieses zu erreichen. Er ist ja schon Mitglied darin. Alle IPs aus dem 1.0/24er Netz sind somit direkt vom VPN Server aus erreichbar. Das zeigt eben dieser eine Eintrag mit dem "*" -> lokales Interface sozusagen.

 

[ara1]

ist auf dem VPN Server überhaupt Routing aktiviert?

echo 1 > /proc/sys/net/ipv4/ip_forward

 

[chrizz9988]

ist auf dem VPN Server überhaupt Routing aktiviert?

echo 1 > /proc/sys/net/ipv4/ip_forward

Obwohl ich oben geschrieben habe, dass ich es auf 1 gesetzt habe (in meinem Eröffnungspost), wusste ich (natürlich) nicht, dass der Wert jedes mal nach Serverneustart wieder auf 0 gesetzt wird...

Danke!!! Ich habe darüber hinaus, heute wild durch die Gegend gepingt und den Traffic auf verschiedenen PCs überwacht. Habe dazu mal mein Netzwerkdiagramm angepasst und einen 2. PC im LAN hinzugefügt.



Ping vom 192.168.2.6 (VPN-Client) auf 192.168.1.1 (Router des 192.168.1.0/24 LANs) ==> funktioniert nun
Ping vom 192.168.1.2 (Win7-PC im 192.168.1.0/24 LAN) auf 192.168.2.6 ==> funktioniert auch

Aber:
Ping vom 192.168.2.6 auf 192.168.1.2 funktioniert nicht.

Und jetzt kommt der Hammer:
Mit tcpdump (für Windows) habe ich den 192.168.1.2 überwacht. Und der Ping kommt an. Und ein Reply wird zurück verschickt und verschwindet (wo auch immer).

Und nun der Oberhammer:
Pinge ich während des Pings vom 192.168.2.6 auf 192.168.1.2 kurz(!) vom 192.168.1.2 auf den 192.168.2.6 zurück, so klappt der Ping vom vom 192.168.2.6 auf 192.168.1.2 für kurze Zeit (10-15 Sekunden), auch wenn der Ping vom 192.168.1.2 auf den 192.168.2.6 bereits beendet ist(!!!) Quasi wie ein Ping-Hole-Punching

Kann sich das jemand erklären???

(es MUSS ja eigentlich am Router (192.168.1.1) liegen, denn der Ping zum Router funktioniert ja vom 192.168.2.6 aus, und der 192.168.1.2 ist ja quasi "hinter" dem Router.)

 

[ara1]

musst irgendwo in /etc/rc... IP_Forward auf yes setzen, dann bleibt's auch dauerhaft.
mh, zu dem Phänomen: joa, wahrscheinlich die Firewall des Routers. Vermutlich hast du nur eine Allow-Regel für VPN->LAN, aber nicht andersrum.

 

[frankie2209]

musst irgendwo in /etc/rc... IP_Forward auf yes setzen, dann bleibt's auch dauerhaft.

Zur Vollständigkeit:
/etc/sysctl.conf:
net.ipv4.ip_forward = 1

(bei mir musste man die Zeile nur auskommentieren)

Ansonsten scheint jetzt alles (so weit) zu funktionieren. Die meisten Clients kann ich aus dem VPN in das andere LAN anpingen und es kommt etwas zurück. Warum das manchmal nicht klappt, ist mir zwar noch schleierhaft, aber es ist ja erstmal eine Testinstallation.

Eine Frage noch: Kann / soll ich das Thema als "gelöst" markieren?