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
ifconfig Client
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
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
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: 05.11.2024 um 13: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 !
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,
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.
10.254.1.1 Server-IP
10.254.1.2 Client-IP
...und du solltest das Clientnetz vom Server und umgekehrt erreichen.
Gruß orcape
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 aufgeroutet wird.
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
..."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 ??
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 ??
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