OpenVPN Routing Problem - Verbindung nur "Einbahnstraße"

[t_ahrens]

Hi,

ich habe noch nicht viel Erfahrung mit OPNsense gesammelt, bin aber durchaus mit den Themen OpenVPN, Routing, Firewall etc. vertraut.

Nun habe ich zum ersten Mal eine OPNsense FW (OPNsense 20.7.8-amd64) eingesetzt, und grundsätzlich hat alles super funktioniert. Nur mit einem vermeintlich kleinen Problem schlage ich mich jetzt schon länger rum...

Die OPNsense steht in der Unternehmenszentrale, und per VPN soll sich ein Remote-PC verbinden, der als Ziel für ein ausgelagertes Backup dient. Als Protokoll soll ausschließlich IPv4 genutzt werden. Ich habe das auf Basis der Anleitung aus der OPNsense Doku eingerichtet (Road Warrior, alternativ auch Site to Site probiert).

Leider ist es jetzt so, dass der Remote-PC die Verbindung zwar aufbaut, und von diesem aus auf alle Ressourcen in der Zentrale zugegriffen werden kann, aber umgekehrt (Server Zentrale -> Backup Remote-PC) funktioniert es nicht. Mit der alten Lösung, ebenfalls auf Basis von OpenVPN, hat es aber bislang ohne Probleme geklappt.

Ich habe mir daran schon die Zähne ausgebissen, und mit Routing, Firewall, Bridgeing, NAT usw. viele Tipps aus diesem Forum und anderen Quellen ausprobiert, es klappt einfach nicht...

Stand der Dinge sieht folgendermaßen aus:

LAN in der Zentrale:   192.168.50.0/24
Tunnelnetz:   192.168.55.0/24
Tunnel"eingang" Zentrale:   192.168.55.1
Tunnel"ausgang" Remote-PC:   192.168.55.2
Adresse Remote-PC/LAN:   196.100.100.62/32 bzw. .0/24  (Nicht konform zu RFC1918, ich weiß...)
Route auf OPNsense:   196.100.100.0/24 über GW 192.168.55.2 (hat OpvenVPN wohl gesetzt)
Firewallregeln OPNsense: Ausgehend alles erlaubt
Firewallregeln Remote-PC: zum Testen deaktiviert (Windows FW)

Vom Router selbst aus (Webinterface / SSH-Konsole) kann ich den Tunnelausgang (192.168.55.2) anpingen, den Remote-PC aber nicht. Wenn ich dort mit Wireshark "lausche", kommt über den VPN-Tunnel auch gar nichts an.

Aus dem Netz der Zentrale heraus kann ich noch nicht einmal die Anfangs- und Endpunkte des VPN-Tunnels anpingen. Im Log der Firewall tauchen "block actions" mit der angepingten IP als Ziel auf, aber angeblich kommen die auf dem externen Interface rein?!

Und wenn ich die Route zum Ziel von dem Server in der Zentrale aus trace, dann ignoriert der Router offensichtlich die gesetzte Route, die Pakete werden über die Standardroute (Provider) ins Internet geschickt, und verschwinden dann über England nach Japan...

Hat jemand eine Idee, woran es liegen könnte? Oder vielleicht einen Hinweis, wie sich das Routing im Detail debuggen kann? Welcher Prozess ist für das Rounting zuständig, und kann ich irgendwie mitloggen, welches Routing warum gewählt wird, und weshalb die Pakete statt über die gesetzte Route über die Default Route geschickt werden?

Beste Grüße
Thorger

[Gauss23]

Grundsätzlich ist Firewall:Log Files:Live View der erste Punkt, wo man nachschaut, ob Pakete überhaupt zugelassen werden.

Mich macht

Firewallregeln OPNsense: Ausgehend alles erlaubt

stutzig. Was ist das für eine Regel?

Eigentlich ist das Regelkonzept so, dass man die Regeln für die Pakete auf dem Interface anlegt, wo das Paket auf die OPNsense eintrifft.

Also wenn Du vom OpenVPN Netz ins LAN willst hast du eine Regel mit OpenVPN, Richtung IN, Source das OpenVPN-Client Netz (und ggf weitere Netze), Destination Dein Lan

Und auf dem LAN eine Regel, die eben die Pakete auch Richtung OpenVPN Netz zulässt.

Baut der Remote-PC die Verbindung direkt auf? Dann wäre die 196er IP ja total irrelevant. Die dürfte die OpenVPN Box ja auch gar nicht kennen oder hast Du die irgendwo eingetragen?

Vom Server in der Zentrale solltest du auf die 192.168.55.2 zugreifen können, nicht aber auf 196.100.100.62.

[t_ahrens]

Grundsätzlich ist Firewall:Log Files:Live View der erste Punkt, wo man nachschaut, ob Pakete überhaupt zugelassen werden.

Das habe ich gemacht, siehe oben. Aber da war für mich nichts zu erkennen, was ich mit meinem Problem in Verbindung gebracht habe.

Mich macht

Firewallregeln OPNsense: Ausgehend alles erlaubt

stutzig. Was ist das für eine Regel?

Damit meine ich die Standardregel auf dem LAN Interface, die in Richtung "in" alles erlaubt, was als Quelle das LAN-Netz hat. Vielleicht bin ich mit den Begrifflichkeiten in / out auch noch auf dem Holzweg. Bezieht sich das auf "in die Firewall rein, aus der Firewall raus" oder auf "von der in-Seite durch die Firewall durch"? Da sind die Konzepte ja tlw. unterschiedlich, und für die pf/Opnsense bin ich da noch nicht schlau draus geworden...

Bei der Regel habe ich aber beim Nachgucken festgestellt, dass ich noch ein festes Gateway eingetragen hatte. Nachdem das nun auf "default" steht (= "use system routing table") kann ich immerhin den Anfang des Tunnels anpingen, die andere Seite aber nach wie vor nicht...

Eigentlich ist das Regelkonzept so, dass man die Regeln für die Pakete auf dem Interface anlegt, wo das Paket auf die OPNsense eintrifft.

Also wenn Du vom OpenVPN Netz ins LAN willst hast du eine Regel mit OpenVPN, Richtung IN, Source das OpenVPN-Client Netz (und ggf weitere Netze), Destination Dein Lan

Die gibt es, gemäß Anleitung erstellt, und der Weg funktioniert ja auch.

Und auf dem LAN eine Regel, die eben die Pakete auch Richtung OpenVPN Netz zulässt.

Da war ich eben der Meinung, dass die die oben beschriebene "Default allow LAN to any rule" das ermöglicht, also dass alles, was aus dem LAN kommt, auf dem Interface gem. Routing Tabelle auch wieder raus darf.

Baut der Remote-PC die Verbindung direkt auf? Dann wäre die 196er IP ja total irrelevant. Die dürfte die OpenVPN Box ja auch gar nicht kennen oder hast Du die irgendwo eingetragen?

Vom Server in der Zentrale solltest du auf die 192.168.55.2 zugreifen können, nicht aber auf 196.100.100.62.

Den Weg über die .55.2 hatte ich auch erst im Sinn, aber nachdem das nicht funktionierte, habe ich sinngemäß wie beim "Site to Site" die Netze "verheiratet", und das Netz des Clients (bestehend nur aus dessen IP) auf dem Server eingetragen.

Das sollte aus meiner Sicht durch die FW-Regeln abgedeckt sein (ich sehe auch keinen entsprechenden "block" Eintrag im Log), und durch die Routen auch (siehe oben).

Unter System > Routes > Status sind folgende Routen zu finden (die hoffentlich auch genutzt werden?):

Proto   Destination             Gateway            Flags     Use     MTU       Netif
ipv4     192.168.55.2           link#9               UH        0        1500       ovpns1
ipv4     196.100.100.0/24    192.168.55.2     UGS        0        1500       ovpns1

Sieht für mich ganz plausibe aus, auch wenn ich nicht genau weiß, was "link#9" oder die Flags bedeuten.

[t_ahrens]

PS:

Im Live View des FW Logs siehe ich

      pass   ovpns1   out   Feb 16 14:09:18   192.168.50.108   192.168.55.2   icmp

Aber es scheint keine Antwort zu kommen?

[Gauss23]

Aha, da kommen wir der Sache näher. Ich denke Du brauchst noch einen Client Specific Override für diese Verbindung, wo die Remote Netze nochmal drin stehen. Darüber bin ich auch schon gestolpert. Der CN muss genau der sein, den Du bei der Verbindung verwendest. Also bei Connection Status nachschauen und den CN genau so kopieren. Dann sollte es laufen. Wobei ich mir nun nicht klar bin, ob der gegnerische Client was mit der Site-to-Site Verbindung anfangen kann.

[t_ahrens]

Ich habe den Fehler jetzt identifiziert, es war tatsächlich das Gateway, das ich - warum auch immer - bei der "LAN to any" Route eingetragen hatte.

Es hätte also vorhin schon wieder gehen sollen, wenn ich nicht an diversen anderen Stellen (u.a. am Client) zwischenzeitlich so viel "zum Testen" verstellt gehabt hätte...

Nun ist meine Konfig wieder sauber, und entspricht mehr oder weniger auch der Anleitung aus der Doku, nur dass ich jetzt einen Shared Key verwende, anstatt des SSL/TLS + Auth Verfahrens. Hat den Vorteil, dass ich die VPN-Verbindung auf dem PC problemlos als Dienst starten kann.

Darüber kann ich "das Tunnelende" vom Server aus erreichen. Das reicht dem Server auch als Ziel, wie wir ja beide schon vermutet hatten. Warum sich das "Remote LAN" nicht erreichen lässt, ist mir zwar noch unverständlich, aber am Ende auch egal. Vielleicht liegt es wirklich daran, dass es ein PC mit Clientinstallation ist, und keine "echte" Serverinstallation...

Gut, dass wir darüber gesprochen haben. Ansonsten hätte ich den Fehler in zwei Wochen noch nicht gefunden. Auf die Idee, die LAN Route zu checken, wäre ich in dem Zusammenhang nie im Leben gekommen. Danke!