[Gelöst] Ges. Traffic durch Tunnel (OpenVPN Client Win 7 -> OpenVPN Srv pfSense)

[peterhart]

Hallo,
mein Name ist Peter und ich habe mich in diesem Forum heute angemeldet, aber ich lese
schon seit ca. einem Jahr hier mit.

Ich setze seit vielen Jahren eine pfSense als Router und Firewall auf einem Embedded
Board ein.
Nach einer Hardwareerneuerung (ALIX.2D13) mit einer neuen Version der pfSense Sw
(2.1.4-RELEASE), habe ich auf diesem System einen OpenVPN Server eingerichtet.

Ziel soll es sein, dass ein OpenVPN Client (Windows 7) über das Internet einen Tunnel
zum OpenVPN Server der pfSense aufbaut.
Der gesamte Datenverkehr soll dann durch den Tunnel zum OpenVPN Server der pfSense
geführt werden.

In Teilen funktioniert das Vorhaben auch.
Ich erreiche vom OpenVPN Client (Windows 7) durch den Tunnel die Netzwerke LAN, DMZ
und WLAN. -> siehe Übersicht 1

Was nicht funktioniert ist das Routing in das Internet durch den Tunnel über den OpenVPN
Server der pfSense.

Woran kann das liegen?

Was mir aufgefallen ist, das ist die merkwürdige Adresszuweisung im Tunnel Netzwerk.
So taucht in der Routingtabelle auf dem OpenVPN Server neben der eigentlichen
openvpn Schnittstelle 192.168.200.1 noch eine weitere IP-Adresse 192.168.200.2 auf.
Diese 192.168.200.2 ist aber nicht erreichbar. -> siehe Übersicht 1

Auf dem OpenVPN Client (Windows 7) wird neben der Zuweisung der Client IP
192.168.200.6 dann auf einmal ein Gateway und DHCP mit der IP 192.168.200.5
zugewiesen. Die IP-Adresse 192.168.200.5 ist nicht erreichbar.
Mit dem Befehl tracert wird dann aber das richtige Gateway 192.168.200.1 verwendet. -> siehe Übersicht 2

Irgendwo ist der Wurm drin!

Zur besseren Übersicht wurden im Anhang einige Infos hinzugefügt!

Kann mir jemand helfen?

Gruß
Peter

[rubinho]

Hi, du hast den Befehl redirect-Gateway in der Client-Config stehen.
Kannst du mal statt auf dem Client den Befehl auf dem Server aktivieren und testen ob es dann geht ?

Am Server kannst du einen Haken setzen "Redirect Gateway  (Force all client generated traffic through the tunnel.)"

Oder willst du nur das dieser eine Client den kompletten Traffic tunnelt ?

Gruß
Rubinho

[peterhart]

Hallo Rubinho,
ja, ich will das nur der eine Client den kompletten Traffic tunnelt.
Aber ich hatte Deine Anmerkungen bereits im Vorfeld getestet.
Leider ohne Erfolg.

Gruß
Peter

[rubinho]

Sry, hat etwas länger gedauert.

Also, zeig uns doch mal die Firewallrules von deinem OVPN Interface einen Tracert von deinem Win7 Rechner ins Internet (z.b. 8.8.8.8 )
Und wie hast du das Outbound NAT stehen… Automatisch oder Manual ?
Wenn Manual, hast du eine Translation Rule für das VPN-Netz eingetragen ?

[peterhart]

Hallo,
Outbound NAT steht auf Automatisch
Die FW Rules sind:
Schnittstelle OpenVPN: any
Schnittstelle WAN: any -> WANadress UDP 1194

Eine DNS Auflösung konnte nicht erfolgen.
Ein Ping o.ä. auf eine WWW Adresse oder IP ergab Zielnetz nicht erreichbar.

Ich bin ja wirklich kein Anfänger und es hat mir keine Ruhe gelassen.
Ich bin mir auch überhaupt nicht sicher was zum Ziel geführt hat, aber z. Z. funktioniert es.

Was habe ich gemacht:
Da weder "Redirect Gateway" auf dem Client noch "Redirect Gateway Force all client generated
traffic through the tunnel." auf dem Server eine Veränderung brachte, habe ich diese Option auf
dem Server gelassen.
Wie oben erwähnt, konnte ich über den Tunnel alle NW auf der pSense problemlos erreichen, nur
eben keine Route ins Internet.

Da ich davon ausgegangen bin das es nicht am Server lag, habe ich den Client in Verdacht gehabt.
Manuell löschte ich einzelne Routen und setzte diese neu. Das brachte zunächst keinen Erfolg, was
mich stutzig machte. Vor allem das eine Namensauflösung immer mit DNS nicht erreichbar endete
und ein Ping an der Tunnelschnittstelle am Clint endete, war sehr merkwürdig.
Aus Erfahrungen mit Windows weiß ich das es manchmal Probleme mit den Winsock Einträgen und
TCP/IP Stacks geben kann und so setzte ich mit den u. a. Befehlen alles auf Standard zurück.

netsh winsock reset catalog

netsh int ipv4 reset reset.log

Jetzt sehen die Routingeinträge auf dem Client etwas anders aus.
Immer noch merkwürdig, aber es funktioniert jetzt.

Ich kann aber erst nächste Woche mit einem anderen Client nochmal Tests durchführen.

Im Anhang habe ich die Routingtabelle vom OpenVPN Client (Windows 7)  hinzugefügt.
Trotz des höheren METRIC Wertes, wird der gesamte Traffic durch den Tunnel geführt.
Nur die Namensauflösung wird noch versucht über die DNS Server meines ISP (1&1) durchzuführen.
Wenn ich aber den METRIC Wert des Tunnels auf 10 setze, wird auch der richtige DNS Server
8.8.8.8 verwendet.

Gruß
Peter

[rubinho]

Gut, das Ganze verstehe ich jetzt auch nicht so wirklich. Aber Hauptsache es geht jetzt :D

[peterhart]

Hallo,
danke nochmal für Deine Anregungen.

Was ich immer noch nicht so richtig verstehe, ist die "komische" Adressvergabe der IP's für den Tunnel (siehe
meine Anmerkungen im 1. Beitrag).
Weiter wundert mich die SubNet Mask 128.0.0.0 für den Tunnel (siehe letztes Bild).

Vielleicht kann das ja mal jemand erklären!?

Gruß
Peter

[BeNe]

Weiter wundert mich die SubNet Mask 128.0.0.0 für den Tunnel (siehe letztes Bild).

Hier zwei Links zu dem Thema –> https://www.astaro.org/gateway-products/general-discussion/44924-route-problems-openvpn-through-local-astaro-firewall.html#post218485
und hier noch –> http://serverfault.com/questions/312860/why-openvpn-use-network-0-0-0-0-netmask-128-0-0-0-as-default-route

[peterhart]

Danke für die Infos!

[peterhart]

Hallo,
um nochmal auf die Routingtabelle zurück zukommen.

Wenn ich das richtig verstanden habe, resultiert das Geheimnis des "merkwürdigen" Eintrages der Netzwerkmaske 128..0.0.0 in meiner
Routingtabelle aus der Festlegung der bestmöglichen Route (in diesem Fall durch den Tunnel).

Das Verfahren nennt sich "Longest Prefix Match".
D.h., mit diesem Verfahren wird ein Paket nur über die Schnittstelle weitergeleitet, die eine maximale Übereinstimmung mit der Zieladresse hat.

Also:
Netzwerkziel    Netzwerkmaske    Gateway              Schnittstelle        Metrik
0.0.0.0            0.0.0.0                192.168.77.254  192.168.77.116    10
0.0.0.0        128.0.0.0                192.168.200.5    192.168.200.6      25

Hier wird die Route nicht aufgrund des Metric Wertes festgelegt, sondern anhand der der Netzwerkmaske (eben der maximale Übereinstimmung mit der Zieladresse).
Somit gehen die Datenpakete über die 2. Route (Tunnel).

Dann wäre nur noch eine Frage offen:

Mir ist aufgefallen, dass in der Routingtabelle auf dem OpenVPN Server neben der eigentlichen
openvpn Schnittstelle 192.168.200.1 noch eine weitere IP-Adresse 192.168.200.2 auftaucht.
Diese 192.168.200.2 ist aber nicht erreichbar.

Auf dem OpenVPN Client (Windows 7) wird neben der Zuweisung der Client IP 192.168.200.6
dann auf einmal ein Gateway mit der IP 192.168.200.5 zugewiesen.
Die IP-Adresse 192.168.200.5 ist nicht erreichbar.

Die Verbindung geht aber über das richtige GW 192.168.200.1 (z. B. mit Tracert getestet).

Was hat das zu bedeuten?

Gruß
Peter