09.01.2013, aktualisiert um 00:52:38 Uhr

14437

OpenVPN Routen werden nicht korrekt übergeben (PfSense)

Hallo Leute
Ich hoffe ihr könnt mir beim folgenden Problem weiter helfen.

Gemäss der Anleitung von aqui, habe ich in einer virtuellen Umgebung versucht, zwei PfSense Router anhand von OpenVPN zu verbinden. Die Verbindung baut sich auch auf. Hier einige Screenshots von den Konfigurationen her.

Entschuldigt die komische Zeichnung (hatte kein Zugriff auf Visio).

Server Konfiguration

Server Konfiguration

Client Konfiguration

Client Konfiguration

Da es es sich nur um einen Test handelt, sind die Firewall Regeln auf praktisch allen Adaptern so eingestellt, da jeglichder Verkehr erlaubt wird (WAN, LAN, OpenVPN (auf beiden Routern)). Die VPN Verbindung baut sich grundsätzlich auf, jedoch gibt es mit dem Routing ganz komische Probleme.

Server OpenVPN Status

Client OpenVPN Status

Der Client aus dem Netz 10.1.1.0/24, kann einen Client aus dem Remotenetz (10.2.1.0/24) nicht anpingen. Umgekehrt das gleiche. Gehe ich jedoch auf dem Router (OpenVPN Client) per Shell drauf, kann ich das Netz 10.1.1.0/24 erreichen. WSchaut man sich per ifconfig die Einstellungen an, erkennt man bei den OpenVPN Adaptern folgendes,

ifconfig Server

ovpns1: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1500
	options=80000<LINKSTATE>
	inet6 fe80::20c:29ff:feee:f7ea%ovpns1 prefixlen 64 scopeid 0x9 
	**inet 10.254.1.1 --> 10.254.1.2 netmask 0xffffffff** 
	nd6 options=3<PERFORMNUD,ACCEPT_RTADV>
	Opened by PID 52164

ifconfig Client

ovpnc1: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1500
	options=80000<LINKSTATE>
	inet6 fe80::20c:29ff:fe75:bfb5%ovpnc1 prefixlen 64 scopeid 0x9 
	**inet 10.254.1.6 --> 10.254.1.5 netmask 0xffffffff** 
	nd6 options=3<PERFORMNUD,ACCEPT_RTADV>
	Opened by PID 17031

Ich weis nicht ob das so korrekt ist, beide Adapter haben jeweils zwei Adressen. Entsprechend sind die Routen aus meiner Sicht komisch. Hier ein relevanter Abschnitt davon.

Route Client

Internet:
Destination        Gateway            Flags    Refs      Use  Netif Expire
default            dsldevice.home     UGS         0      692    em0
10.1.1.0           10.254.1.5         UGS         0        6 ovpnc1
10.2.1.0           link#2             U           0        5    em1
client             link#2             UHS         0        1    lo0
10.254.1.1/32      10.254.1.5         UGS         0        1 ovpnc1
10.254.1.5         link#9             UH          0        1 ovpnc1
10.254.1.6         link#9             UHS         0        0    lo0

Im grunde möchte ich, das zwischen beiden Netzen (10.1.1.0/24 und 10.2.1.0/24) geroutet wird. Später sollen weitere OpenVPN Clients auch eine gleiche Verbindung mit dem Netz 10.1.1.0/24 haben (Remote Access).

Bin für jede Hilfe sehr dankbar.

Gruss
Kaioshin

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

Content-ID: 196650

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

Ausgedruckt am: 24.11.2024 um 03:11 Uhr

8 Kommentare

Neuester Kommentar

Das "route" Kommando ist eigentlich überflüssig. Einzig sollte ein "Push route" reichen. Vermutlich gibt es da ein Konflikt, zumal das "route" Kommando unsinnig ist, denn da fehlt ein next Hop Gateway.
Du kannst dir unter Diagnostics die Route Table der OVPN Router ansehen ob die entsprechenden IP Netze jeweils in die Tunnelinterfaces geroutet werden.
Die Clients sollten natürlich allesamt auf die OVPN Router als default Gateway eingetragen haben !

Hallo Kaioshin,

Im grunde möchte ich, das zwischen beiden Netzen (10.1.1.0/24 und 10.2.1.0/24)
geroutet wird.

Dann sollte die Server-Config auf Peer-to-Peer SSL/TLS stehen und nicht auf
Remote Access.
Dann kannst Du auch Dein remotes Netzwerk in der Eingabemaske des pfSense-OVPN-Servers eingeben und wie hier Aqui schon richtig sagt, ist das "route" Kommando unter "advanced" dann überflüssig, Du hast ja bereits in der Server Config das remote Netz hinter dem OVPN-Client eingetragen.
Der "push" Eintrag dort ist so OK, er teilt dem OVPN-Client mit, welches Netz hinter dem Server liegt.
Was Dir noch fehlt sind Einträge unter "Client Specific Overrides" auf dem Server.
Dort sind die Serverangaben einzutragen und was ganz wichtig ist,
ein "iroute" Befehl zum remoten OVPN-Clientnetz.

iroute 10.2.1.0 255.255.255.0;

Dann erhält´s Du ein Virtuelles Netz, welches nicht mehr aus 4 Tunnel-IP´s besteht, sondern nur noch aus...
10.254.1.1 Server-IP
10.254.1.2 Client-IP
...und du solltest das Clientnetz vom Server und umgekehrt erreichen.

Gruß orcape

Hallo aqui

Ich dachte das "route"-Kommando wäre für den Server insofern wichtig, dass wen mehrere Netzte hinter den Clients liegen, diese durch die Information (anhand des route Befehls) erreicht werden könne. In meinem Beispiel ist das (jetzt) nicht der Fall.

denn da fehlt ein next Hop Gateway.

Wäre das nicht der OpenVPN Adapter des Clients?

Die Clients sollten natürlich allesamt auf die OVPN Router als default Gateway eingetragen haben !

Das ist natürlich der Fall. Die Clients hängen direkt an den Router (OVPN Server, OVPN Client).

Wenn ich den OpenVPN Systemlog anschaue, stelle ich einen Fehler fest:

Jan 9 19:13:05 openvpn[55058]: ERROR: FreeBSD route add command failed: external program exited with error status: 1
Meistens zweimal hintereinander aufgelistet.

Im PfSense Forum lass ich, dass einer mit derselben Konfiguration (die die betroffene Person hatte) den Fehler nicht feststelle, wenn er auf eine frühere Firmware upgradete.

Was ganz komisch ist, ist dass der Router (Client) selber, das Netz 10.1.1.0/24 und die Clients erreicht. Wenn ich auf dem Client (10.1.1.1) Wireshark laufen lasse und danach einen Ping vom OpenVPN Client Router starte, stelle ich im Wireshark eine Anfrage von 10.254.1.6 fest. Der Client (10.2.1.3) hinter dem OpenVPN Router Client kann hingegen das fremde Netz nicht erreichen.

Ich habe nun den Client auf die neue Version 2.0.2 geupdatet. Der Fehler besteht aber weiterhin (vorher hatte ich 2.0.1). Der Server befindet sich auf die Version 2.0.1.

Danke für deine Hilfe.

Gruss,
Kaioshin

Hallo orcape

Dann sollte die Server-Config auf Peer-to-Peer SSL/TLS stehen und nicht auf
Remote Access.

Werde ich jetzt mal so einstellen.

Dann kannst Du auch Dein remotes Netzwerk in der Eingabemaske des pfSense-OVPN-Servers eingeben und wie hier Aqui schon > richtig sagt, ist das "route" Kommando unter "advanced" dann überflüssig, Du hast ja bereits in der Server Config das remote Netz hinter dem OVPN-Client eingetragen.

Als Remote-Netz auf der Serverseite, habe ich das lokale Netz des Servers eingetragen (10.1.1.0/24). Aber ich dachte mir, dass ich vielleicht die lokalen Netzte des Server per push an den Client übertrage - da es später mehrere sind. Weil nach dem Tutorial musste ich da - wenn ich mich nicht irre - dort das für den Client zu erreichende Netz eintragen.
Und die hinter dem Client liegenden Netzte per route Befehl am Server mitteilen. Wobei ich jetzt sehe, dass mit der "Peer-to-Peer" Einstellung, ein weiteres Eingabefeld auftaucht: "Remote Network". Trotzdem müsste ich aber bei Vorhandensein mehrere Netzte, mit den Befehlen unten arbeiten, oder?!?

Was Dir noch fehlt sind Einträge unter "Client Specific Overrides" auf dem Server.
Dort sind die Serverangaben einzutragen und was ganz wichtig ist,
ein "iroute" Befehl zum remoten OVPN-Clientnetz.

Werde ich jetzt machen.

Danke für deine Hilfe.

Gruss
Kaioshin

PS: Entschuldigt den Doppelpost.

..."stelle ich im Wireshark eine Anfrage von 10.254.1.6 fest. Der Client (10.2.1.3) hinter dem OpenVPN Router Client kann hingegen das fremde Netz nicht erreichen."
Das ist auch insofern logisch, das du die AbsenderIP Adresse nicht mitgegeben hast. In den pfSense Diagnostics kannst du die auswählen !
Letztlich ist es aber egal wenn der 10.254.1.6er Ping am Client ankommt 10.2.1.3 will der auch ein Echo Reply (Ping) and die 10.254.1.6 zurückschicken. Dazu sieht der Client in seine Routing Tabelle ("route print" zeigt dir die), denn es ist ja nicht sein loakles Netz. Er wird das Antwortpaket also an sein Default Gateway schciken, was hoffentlich der pfSense Router ist. Hier solltest du jetzt unter Statistics auch mal nachsehen wie dessen Routing Tabelle aussieht !!
Die zeiht dir nämlich genau WO das 10.254.1er Paket hingeroutet wird.
Fazit: Irgendwas ist total vermurkst bei den Routen. Eigentlich mehr als verwunderlich, denn wenn man OVPN einfach ohne Schnickschnack einrichtet funktioniert sowas schon in einer simplen Grundkonfiguration.
Unverständlich also was du da machst. Sagen die pfSense Logs irgendwas ??

Hallo

Jetzt funktioniert es nun.

Fazit: Irgendwas ist total vermurkst bei den Routen. Eigentlich mehr als verwunderlich, denn wenn man OVPN einfach ohne Schnickschnack einrichtet funktioniert sowas schon in einer simplen Grundkonfiguration.

Ganz am Anfang habe ich beim OVPN-Server, "Remote Access" als Server Mode gewählt. Das führt offensichtlich dazu, dass der verbundene Client auf das Remote-Netz (das lokale Netz auf der Serverseite) zugriff hat. Im Normalfall wäre das beispielsweise jemand, der mit seinem OVPN Client aus einem Arbeitsrechner eine Verbindung aufbaut - um auf entfernte Ressourcen zuzugreifen. Da ich aber eine PfSense als Client verwende, funktioniert natürlich auch der Ping von der PfSense (OVPN Client) aus. Jedoch nicht von den dahinterliegenden Clients. Die Rechner aus dem lokalen Netz des OVPN Servers, konnten auch den OVPN Client (10.254.1.6) erreichen, aber nicht sein lokales Netzwerk. Dafür ist der "Peer to Peer" Modus notwendig.

Mit dieser Einstellung - und den weiteren Konfigurationen bezüglich der "Client Specific Overrides" - funktioniert nun ein gegenseitiges erreichen der lokalen Netze untereinander.

Durch das Umstellen auf "Peer to Peer", kann in der PfSense danach zusätzlich das "Remote Network" eingetragen werden.

Ich muss jetzt nun einfach noch prüfen, wie das aussieht, wenn weitere lokale Netze vorhanden sind. Ich denke diese sollten problemlos mit der "Advanced configuration" mitgegeben werden können.

Danke für eure Hilfe.

Kaioshin

Das ganze funktioniert auch mit Remote-Access ...
Allerdings muss dann in der Advanced Config eine route eingetragen werden ...
z.B.: route 192.168.0.0 255.255.0.0

ich vermute, im Modus "Remote Access" greift der iroute-Eintrag in den overrides nicht ...

PfSense als Client verwende, funktioniert natürlich auch der Ping von der PfSense (OVPN Client) aus. Jedoch nicht von den dahinterliegenden Clients.

Ist ja auch klar, denn dafür müsste die pfSense die Routen in diese IP Netze kennen, was sie aber im Client Mode nicht kann.
Wie du richtig schreibst kennt sie dann nur das remote lokale IP Netz.
Hier musst du logischerweise mit zusätzlichen Routen dafür sorgen das der Client oder der Gegenpart auf der anderen Seite diese IP netze auch in den Tunnel routet.
Dazu ist immer die Routing Tabelle der pfSense hilfreich und der erste Anlaufpunkt (unter "Diagnostics)
Die Tabelle sagt immer wie alle IP Netze die die pfSense kennt zu erreichen sind und über welches Interface.
Fehlen da Routen hast du ein Konfig Problem....wie immer.

Dafür ist der "Peer to Peer" Modus notwendig.

Sehr richtig ! Bei einer LAN zu LAN Kopplung ist das zwingend.

wie das aussieht, wenn weitere lokale Netze vorhanden sind.

Wie gesagt..Advanced mit route oder zusätzliche statische Route ! Noch pfiffiger ist es wenn du mit RIPv2 oder OSPF dynamisch routest dann spart man sich die Frickelei mit den statischen Routen.
Gut wenn nun alles rennt wie es soll