OpenVPN Probleme

[servantofevil]

Moin,

ich habe zwei OpenVPN Server erstellt. Zu dem ersten verbindet sich ein Windows Rechner und zu dem zweiten verbindet sich ein Raspi.
Beide Verbindungen stehen und ich kann vom Windows Rechner aus auf das gesamte Netz hinter der OPNSense zugreifen. Bei der Raspi Verbindung können auch die Clients hinter dem Raspi auf das Netzwerk hinter der OPNSense zugreifen.

Was auch noch funktioniert ist der Ping vom Rechner hinter der OPNSense auf die beiden IP´s des Tunnelnetzwerks (also die IP´s des Endpunktes = ich komme durch den Tunnel an die beiden Remote Gateways)

Was nun leider in beiden Fällen nicht funktioniert ist der Zugriff vom OPNSense Netzwerk zu den beiden VPN Gateways über deren IP´s und somit auch nicht auf dahinter liegende Clients.

Ich hab Client-seitig (also Windows Rechner und Raspi) das Routing aktiviert. Beim Windows Rechner die Firewall komplett ausgeschaltet und beim Raspi alle möglichen iptable Settings probiert, die man so finden kann...

in den Firewall Einstellungen auf der OPNSense hab ich sowohl bei LAN als auch bei OpenVPN (die Gruppenregel, da ich die Interfaces selbst nicht zugewiesen hab) "in any - any".

bei den beiden erstellten openvpn Servern hab ich separate Tunnel Netzwerke angegeben und bei beiden jeweils mein internes "ipv4 local Network" und das "ipv4 Remote Network"
TOS, inter-client communication, dynamic IP und Topology sind aktiviert.


ping geht wie erwähnt nicht durch
traceroute von der OPNSENSE hört nach Zeile 64 mit jeweils 3 Sternchen auf

zu guter Letzt noch die netstat, die doch auch gut ausschauen?!

Internet:
Destination        Gateway            Flags     Netif Expire
default            84.xxx.xxx.1        UGS      pppoe0
84.xxx.xxx.1        link#8             UH       pppoe0
127.0.0.1          link#5             UH          lo0
172.20.20.0/24     link#10            U        ovpns3
172.20.20.1        link#10            UHS         lo0
172.20.21.0/24     link#11            U        ovpns4
172.20.21.1        link#11            UHS         lo0
176.xxx.xxx.214     link#8             UHS         lo0
192.168.0.0/24     link#2             U          vmx1
192.168.0.1        link#2             UHS         lo0
192.168.2.0/24     link#3             U          vmx2
192.168.2.1        link#3             UHS         lo0
192.168.178.0/24   172.20.21.2        UGS      ovpns4
192.168.179.0/24   172.20.20.2        UGS      ovpns3


wo und wie kann ich mit der Analyse ansetzen?
ping 172.20.x.2 geht
ping 192.168.178.29 (wäre der Rechner mit installiertem openvpn) geht nicht - ich versteh es nicht und hab keinen Ansatz wo ich schauen müsste

[servantofevil]

hab noch ein par Tests gemacht

ping auf den Tunnel Endpunkt wird vom Client Gateway registriert (tcpdump sieht die Pakete) - soweit funktioniert der ping ja auch
auf dem VPN Server selbst sehe ich die Pakete auch auf dem ovpn Interface

soweit also alles wie es sein soll


ping auf die private IP des VPN Gateway wird vom Server genauso registriert und geht auch über das interface wie beim ping auf den Tunnel Endpunkt ABER am Client Gateway kommen diese Pakete nicht an...der tcpdump bleibt leer

es gehen also beide Pakete vom Server raus auf dem entsprechenden korrekten interface
aber nur eins der Pakete erreicht das Client Gateway interface. Warum?!

[JeGr]

Ich vermute du hast die OVPN Server mit Site2Site nicht mit dem Shared Key Mode konfiguriert, sondern sauber mit Site2Site SSL und Zertifikaten? Wie sieht die Serverkonfiguration auf der OPNsense aus? Und hast du Client specific Overrides definiert? Da ein SSL-mode VPN Server prinzipiell mehrere Gegenstellen haben kann - nicht nur eine wie beim SharedKey - ist hier das Verhalten von OpenVPN etwas anders (und dokumentiert), da der VPN Server hier nicht genau sagen kann, an wen er welches Netz wie zurücksenden soll. Auch wenn nur eine Verbindung besteht - es könnten theoretisch mehrere sein, daher wird er nur Pakete rückrouten wenn:

* im VPN Server selbst als Remote Netz das Netz auf der anderen Seite (also hinter Raspi oder Windows GW) angegeben ist
* ein Client Specific Override konfiguriert ist, der den Client (Raspi oder Windows Kiste) identifiziert (normalerweise über den CN des Zerts) und dort nochmals als Remote Netz das entsprechende Netz drinsteht.

Die erste Angabe im Server ist quasi notwendig um dem VPN Service zu sagen "hey schicke 172.20.20.x an ovpns3" und der zweite im CSO damit er weiß, dass er das dem Client XY zurouten soll, der via ovpns3 verbunden ist.

Ist ein tick komplizierter als shared key aber wenn mans mal verstanden hat, gehts ganz einfach

Cheers
\jens

[servantofevil]

Moin,

ich hatte extra separate Server erstellt (dadurch in den netstat auch ovpn3 und ovpn4 mit entsprechender Route).
Overrides hat er nicht genommen, egal ob ich "Force CSO Login Matching" gesetzt hab oder nicht.

Ich hab es dann auch aufgegeben, weil es mir unerklärlich war, dass in der Routing Tabelle alles gut ist, ich auch den Tunnel-Endpunkt anpingen kann, aber zum client Netz hin kein Ping durch geht. Von den Clients aus ins OPNSense Netz lief der Ping einwandfrei (da muss die OPNSense doch auch wissen, wie es wieder zurück geht?!)

und Ping ist nicht das einzige was ich getestet hab.
Auhc der Mitschnitt der Pakete zeigte auf den OVPN Interfaces, dass die Daten raus gehen..aber es kam nix zurück.

Ich vermute du hast die OVPN Server mit Site2Site nicht mit dem Shared Key Mode konfiguriert, sondern sauber mit Site2Site SSL und Zertifikaten? Wie sieht die Serverkonfiguration auf der OPNsense aus? Und hast du Client specific Overrides definiert? Da ein SSL-mode VPN Server prinzipiell mehrere Gegenstellen haben kann - nicht nur eine wie beim SharedKey - ist hier das Verhalten von OpenVPN etwas anders (und dokumentiert), da der VPN Server hier nicht genau sagen kann, an wen er welches Netz wie zurücksenden soll. Auch wenn nur eine Verbindung besteht - es könnten theoretisch mehrere sein, daher wird er nur Pakete rückrouten wenn:

* im VPN Server selbst als Remote Netz das Netz auf der anderen Seite (also hinter Raspi oder Windows GW) angegeben ist
* ein Client Specific Override konfiguriert ist, der den Client (Raspi oder Windows Kiste) identifiziert (normalerweise über den CN des Zerts) und dort nochmals als Remote Netz das entsprechende Netz drinsteht.

Die erste Angabe im Server ist quasi notwendig um dem VPN Service zu sagen "hey schicke 172.20.20.x an ovpns3" und der zweite im CSO damit er weiß, dass er das dem Client XY zurouten soll, der via ovpns3 verbunden ist.

Ist ein tick komplizierter als shared key aber wenn mans mal verstanden hat, gehts ganz einfach

Cheers
\jens

[JeGr]

Das natürlich schade, wenn das schon wieder abgebaut ist, sonst hätte man das mal zusammen anschauen können. War sicher nur eine Kleinigkeit die noch gefehlt hat, aber wenn dus mal wieder in Angriff nehmen solltest, sag Bescheid