Servus,
ich habe seltsame Routingprobleme und wahrscheinlich asynchrones Routing. Vorweg: Firewall rules auf den Interfaces testweise any any any any.
Beschreibung:
Tunnel von Site A(Client) auf Site B(Server).
Clientnetz Site A = 10.1.0.0/24
Transfernetz zw. A und B 192.168.0.1/29
Site B hat ein Transfernetz 10.2.0.0/24 an Site C (nicht meine Infratstruktur). Da ist ein GW, der auf Site C Subnetze 10.0.0.0/8 hat.
Opnsense Site B hat eine statische Route 10.0.0.0/8 nach GW 10.2.0.1 (Route 10.0.0.0/8 muss so sein, weil dahinter noch mehr ist)
Was funktioniert:
Gehe ich direkt auf die opnsense Seite A, kann ich eine Adresse Hinter GW Site C erreichen. Tunnel steht also, Routing grundsätzlich richtig. Dabei kommt mein Ping auf 10.4.0.22 von 192.168.0.2 (also der Transfernetz-OpenVPN-IP der Site A)
Was nicht funktioniert:
Komme ich von 10.1.0.10, also dem LAN von Site A mit Ping auf 10.4.0.22 an Site C, werden die Pakete zwar zu 10.4.0.0/24 weitergeleitet (sehe ich im Capture) und kommen an. Die Rückantwort von 10.4.0.0/24 wird von opnsense Site B dann aber nicht über den Tunnel zurück an A geschickt, sondern über deren WAN-Interface. Damit wäre das asynchron.
Ich hab das mit pfSense schon zigfach gebaut. Daher ist das mit der Route an sich alles richtig. Nur mit opnsense gehts nicht und ich finde den Fehler einfach nicht.
Die VPN-Server und Clients haben analog dazu in ihre local und remote networks die entsprechenden Netze eingetragen.
Hat irgendwer eine Idee?
Vielen Dank!
Schau dir mal deine Routing-Tabellen auf B an. Ich glaube nicht das B weiß das 10.1.0.0/24 hinter deinen OpenVPN sitzt.
Du kannst natürlich auch einen ausgehende NAT auf A machen, weil alles aus dem Transfehrnetz funktioniert ja bei dir.
Ja, B wusste nicht, dass das Netz da sitzt. Daher kam ich ja auf asynchrones Routing. Ich hab's in den CSO geschrieben gehabt und dachte eigentlich, das genügt. Dabei muss es im CSO UND(!) in der Serverkonfig stehen.
Das war das ganze Problem... Ich muss noch mehrere Außenstellen per VPN anbinden. Bin mal gespannt, was der Server macht, wenn die alle verbinden. Denn der baut seine Routingtabelle nämlich so, dass weitere Netze, die in einem anderen CSO eingetragen sind, trotzdem auf den Endpunkt der Seite geschickt werden, die das Netz gar nicht hat.
routing.png
Jedenfalls habe ich das gerade so versucht. Siehe Bild. Dabei sollte sie wie folgt aussehen:
192.168.200.32/27 192.168.200.2
192.168.99.0/24 192.168.200.3
Denn:
192.168.200.32/27 steht im CSO für Site A
192.168.99.0/24 steht im CSO für Site E (eine weitere VPN-Außentelle wie Site A)
Quote from: tpf on March 19, 2026, 05:19:15 PMIch muss noch mehrere Außenstellen per VPN anbinden. Bin mal gespannt, was der Server macht, wenn die alle verbinden. Denn der baut seine Routingtabelle nämlich so, dass weitere Netze, die in einem anderen CSO eingetragen sind, trotzdem auf den Endpunkt der Seite geschickt werden, die das Netz gar nicht hat.
Das sieht nur so aus.
Die Route zeigt auf die erstbeste Client-IP. So geht das Route von OPNsense mal in die OpenVPN Instanz. Die routet das dann intern zum jeweiligen Client anhand des CSO.
Das macht pfSense auch nicht anders.