OPenVPN Routing Problem / Default GW Problem

[fw115]

Komm doch am Freitag mal zum virtuellen Stammtisch, dann gucken wir uns den Kram live an.

Der Jens hat mit OpenVPN auch noch deutlich mehr Erfahrung als ich, ich benutz wo ich kann lieber IPsec oder WireGuard.

Stammtisch-Info: https://forum.opnsense.org/index.php?topic=18183.0

Ich hätte auch gerne was anderes, leider bekomme ich von meinem Provider nichts anderes. Ich bin schon froh das ich meine IP Adressen überhaupt so bekomme.

Ich würde wirklich sehr gerne vorbei schauen, leider bin ich genau dieses WE schon verplant. Wie das so ist im Leben.
Und ich merke auch, dass Netzwerken nicht ganz so meine Welt ist (wohl auch der Grund warum ich IPv6 hasse wie die Pest, aber das ist ein anderes Thema).
Vielleicht erbarmt sich ja jemand und schaut mal für 15 min in der Woche danach mit mir auf mein System.
Mal sehen, ansonsten wird das wohl bis zum 22. warten müssen.

Danke an alle für die Hilfe!

[viragomann]

Könntest du bitte mal alle Floating Regeln und alle auf OpenVPN zeigen?

[Patrick M. Hausen]

Ich hätte auch gerne was anderes, leider bekomme ich von meinem Provider nichts anderes. Ich bin schon froh das ich meine IP Adressen überhaupt so bekomme.

Das ist ja auch nicht schlimm - ich mache genau dasselbe für 2 Kunden, die über je einen WireGuard-Tunnel IP-Adressen aus meinem AS aus einem Interface ihrer OPNsense rauströpfeln lassen. Die hatten halt vor 20 Jahren mal eine 2 Mbit Leitung von uns zu astronomischen Preisen und haben sich dann vor ein paar Jahren eine DSL-Leitung der Telekom geklickt und wollten irgendwie unsere Adressen behalten.

Funktioniert alles - der Policy-Kram ist halt nicht ganz trivial.

[fw115]

Hier die Rules:

[fw115]

Ich hätte auch gerne was anderes, leider bekomme ich von meinem Provider nichts anderes. Ich bin schon froh das ich meine IP Adressen überhaupt so bekomme.

Das ist ja auch nicht schlimm - ich mache genau dasselbe für 2 Kunden, die über je einen WireGuard-Tunnel IP-Adressen aus meinem AS aus einem Interface ihrer OPNsense rauströpfeln lassen. Die hatten halt vor 20 Jahren mal eine 2 Mbit Leitung von uns zu astronomischen Preisen und haben sich dann vor ein paar Jahren eine DSL-Leitung der Telekom geklickt und wollten irgendwie unsere Adressen behalten.

Funktioniert alles - der Policy-Kram ist halt nicht ganz trivial.

Das merke ich gerade.

Witzig gerade: Ich kann Webseiten aufrufen aus dem LAN , aber nicht aus dem LAN pingen....

Ich Blick es nich mehr....
Ich würde gerne die Zusammenhänge verstehen und verstehe es nicht. Joa, merkt man am Ergebnis :)

[Patrick M. Hausen]

Dein grundlegendes Verständnisproblem mit den Interfaces verstehe ich nun aber auch nicht ganz. Ich komme von viel Cisco (IOS, PIX, ASA) und vor allem der Secure Computing Sidewinder zur OPNsense und bei jeder anderen Firewall gehört eine Regel auf das Interface, an dem das System hängt, das die Verbindung initiiert. Ist wirklich global so. Bissi Berührung mit Checkpoint hatte ich auch - ebenfalls kein Unterschied.

Weshalb ist das mit den Interfaces so kompliziert in deinem Kopf?

System im Internet will Dinge von den Servern - IP kommt über den Tunnel rein --> Regel muss auf das Tunnel-Interface.
System im LAN will Dinge im Internet --> Regel muss auf das LAN.

Etc. Easy? Oder?

[fw115]

Dein grundlegendes Verständnisproblem mit den Interfaces verstehe ich nun aber auch nicht ganz. Ich komme von viel Cisco (IOS, PIX, ASA) und vor allem der Secure Computing Sidewinder zur OPNsense und bei jeder anderen Firewall gehört eine Regel auf das Interface, an dem das System hängt, das die Verbindung initiiert. Ist wirklich global so. Bissi Berührung mit Checkpoint hatte ich auch - ebenfalls kein Unterschied.

Weshalb ist das mit den Interfaces so kompliziert in deinem Kopf?

System im Internet will Dinge von den Servern - IP kommt über den Tunnel rein --> Regel muss auf das Tunnel-Interface.
System im LAN will Dinge im Internet --> Regel muss auf das LAN.

Etc. Easy? Oder?

Eigntlich ja, ich denke ich stehe mir aus Unsicherheit mit dem neuem System( is das was ich gemacht habe wirklich richtig?) mehr selber im Weg als ich sollte.
Die einzige Firewall die ich kenne, ist eben die Astaro die dann zur Sohopos UTM wurde. Aktuell V9.
In der Astaro hab ich 3 Interfaces. Das war es dann.
LAN
DMZ
WAN
VPN wird gar nicht als Interface wie in der OPNsense definiert.

Da wird kein Interface nochmal zugewiesen wie bei der Opnsense z.B. VPN oder das vlan 132

So sieht z.B das WAN bei der Sophos aus. Ich hab kein extra Vlan Interface das irgenwo assigend werden muss und habe dann auch nur 1 Interface WAN und nicht ein WAN und ein VLAN das mir angezeigt wird.

VLAN Tag rein, erledigt.

Macht das ganze deutlich übersichtlicher und einfacher nachzuvollziehen.

Und so gibt es viele Sachen die bei opsense in Zig Menüs aufgesplittet sind und die config einfach extrem unübersichtlich machen.
Als Anfäger in Opnsense und von der Oberfläche der Astaro ( is für mich eben immer noch Astaro obwohl von Sophos übernommen)kommend, bekommt man einfach einen Fön.

[viragomann]

Hier die Rules:

Ich zitiere dazu Zeilen aus meinem ersten Post in deinem anderen Thread OpenVPN Client Config > sehe den Wald vor lauter Bäumen nicht.:

Wichtig:
- Der OpenVPN Client Instanz musst du ein Interface explizit zuweisen, falls das noch nicht geschehen ist.
- In Firewall: Rules: OpenVPN darf keine Pass-Regel existieren. Jedenfalls keine, die auf die weitergeleiteten Pakete zutrifft.

Das "Wichtig" hatte ich davor gesetzt, weil es unbedingt zu beachten ist, will man Erfolg mit einem solchen Setup haben.

Erkennst du jetzt den Fehler?

[fw115]

Hier die Rules:

Ich zitiere dazu Zeilen aus meinem ersten Post in deinem anderen Thread OpenVPN Client Config > sehe den Wald vor lauter Bäumen nicht.:

Wichtig:
- Der OpenVPN Client Instanz musst du ein Interface explizit zuweisen, falls das noch nicht geschehen ist.
- In Firewall: Rules: OpenVPN darf keine Pass-Regel existieren. Jedenfalls keine, die auf die weitergeleiteten Pakete zutrifft.

Das "Wichtig" hatte ich davor gesetzt, weil es unbedingt zu beachten ist, will man Erfolg mit einem solchen Setup haben.

Erkennst du jetzt den Fehler?

Ja ich erkenne den Fehler das alle Rules die ich in OPENvpn gesetzt habe da raus müssen und in das von mir definierte Interface müssen.

Verstehe aber die unterschiedliche Behandlung der Interfaces nicht, siehe oben das Beispiel vom WAN der Astaro.

Was ist der Sinn dieser Art des Handlings ? Welchen Vorteil hat das ? Welche Einstellungen kann ich evt mehr vornehmen bei dieser Art des Setups ?

Warum die Aufteilung ? Warum nicht nur 1 Interface ?

Ich gehe dann davon aus, dass es sich bei WAN und VLAN132 ähnlich verhält.

[viragomann]

Es geht um reply-to. Ich dachte, Patrick hatte es eh auch im anderen Tread schon (mehrmals) erwähnt.

Die Sache ist, standardmäßig folgen den Pakete der Routing-Tabelle. Hier geht es konkret um die Antwortpakete der DMZ. Die Default-Route zeigt nun aber auf das WAN GW, wenn in OpenVPN "route no-pull" nicht gesetzt ist.

Damit die Pakete dennoch richtig zurück geroutet werden könne, versieht OPNsense die Verbindung mit dem "reply-to" Tag, das das Gateway enthält, wo die Antwort hin soll. Das Tagging passiert durch die Regel, die den eingehenden Traffic (das SYN-Paket) erlaubt. Das Gateway holt sich OPNsense dabei aus der Interface-Konfiguration. Bei OpenVPN wird diese automatisch gemacht, also auch das Gateway.

Damit dieses Tagging funktioniert, muss OPNsense aber eindeutig das Gateway erkennen können. Dafür muss die zutreffende Regel, eindeutig einem Interface zuordenbar sein. Das gilt aber natürlich nicht für Floating Regeln und Regeln auf eine Interface-Gruppe. Diese können ja auf mehreren Interfaces definiert sein. OpenVPN ist aber eine Gruppe, die sämtliche OpenVPN Interfaces enthält, auch wenn du nur eine Instanz betreibst. Daher kein reply-to.

Wenn du erst eine Erklärung für dein Verständnis benötigst, um die Anweisungen zu befolgen, hättest du aber schon früher danach fragen können. Wir erklären alle gerne, aber zumindest ich nicht gerne unnötig, und manche interessieren die Hintergründe auch gar nicht.

Um die Regeln zu übersiedeln, brauchst du sie nur zu editieren und das Interface ändern, falls dir die Handhabe nicht geläufig ist.

[fw115]

OK, ich habe verstanden, dass OPENvpn ein Globales Interface ist, in das alle Rules rein kommmen, die für alle erstellten VPNs gültig sind.

Nun habe ich alle Rules aus OPENvpn entfernt und in mein legacy Interface  VPN_Leg überführt, ich habe im Legacy Client in "Don't pull Routes" einen Haken drin.

Keine weiteren Änderungen.

Ergebnis:

nicht mehr erreichbar. Der Tunnel steht und ist connected allerdings finden sich folgende Fehler im Logfile:

2025-08-05T10:46:00   Warning   openvpn_client2    ERROR: FreeBSD route add command failed: external program exited with error status: 1
2025-08-05T10:46:00   Error   openvpn_client2    Options error: option 'redirect-gateway' cannot be used in this context ([PUSH-OPTIONS])
2025-08-05T10:46:00   Error   openvpn_client2    Options error: option 'route-ipv6' cannot be used in this context ([PUSH-OPTIONS])
2025-08-05T10:45:59   Warning   openvpn_client2    NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
2025-08-05T10:45:59   Warning   openvpn_client2    WARNING: No server certificate verification method has been enabled.  See http://openvpn.net/howto.html#mitm for more info.
2025-08-05T10:45:59   Warning   openvpn_client2    WARNING: using --pull/--client and --ifconfig together is probably not what you want
2025-08-05T10:45:59   Warning   openvpn_client2    DEPRECATED OPTION: --cipher set to 'BF-CBC' but missing in --data-ciphers (AES-256-GCM:AES-128-GCM:CHACHA20-POLY1305). OpenVPN ignores --cipher for cipher negotiations.
2025-08-05T10:45:59   Warning   openvpn_client2    WARNING: Compression for receiving enabled. Compression has been used in the past to break encryption. Sent packets are not compressed unless "allow-compression yes" is also set.
2025-08-05T10:45:59   Error   openvpn_client2    event_wait : Interrupted system call (fd=-1,code=4)

hier nochmal die vpn.conf vom provider:

tls-client
client
dev tun
proto tcp
#proto tcp6
tun-mtu 1500
remote vpn3.xxx.de 1194
verify-x509-name vpn3.xxx.de name
cert cert_vpn.pem
key key_vpn.pem
ca vpn-ca.pem
cipher BF-CBC
comp-lzo
verb 3

[viragomann]

Von dem Log ist mir nur die erste Zeile unklar. Mit "Don't pull Routes" sollte gar kein "route add" ausgeführt werden, es sei denn, du hast in "Remote Network" was eingetragen.

Mit "nicht mehr erreichbar" meinst du deine DMZ aus dem Internet über VPN?
Wenn es ohne "Don't pull Routes" funktioniert sollte es mit der VPN ja nichts zu tun haben. Dann kann es eigentlich nur daran liegen, dass reply-to nicht funktioniert.

Überprüfen kannst du da mit Packet Capture. Funktioniert es nicht, gehen die Antwort-Pakete um WAN raus, entsprechend der Default-Route.
Wenn das so ist, stelle nochmals sicher, dass
- auf OpenVPN keine Pass-Regel aktiv ist.
- in Firewall: Settings: Advanced reply-to nicht deaktiviert ist.
- reply-to in den jeweiligen Firewall-Regeln am VPN_Leg Interface nicht deaktiviert ist (Advanced Features). Du könntest da auch versuchsweise explizit das VPN Gateway angeben.
- die Firewall-Regeln am VPN_Leg auch zutreffen, indem du das Logging aktivierst und es dann im Log überprüfst.

[fw115]

Von dem Log ist mir nur die erste Zeile unklar. Mit "Don't pull Routes" sollte gar kein "route add" ausgeführt werden, es sei denn, du hast in "Remote Network" was eingetragen.

Mit "nicht mehr erreichbar" meinst du deine DMZ aus dem Internet über VPN?
Wenn es ohne "Don't pull Routes" funktioniert sollte es mit der VPN ja nichts zu tun haben. Dann kann es eigentlich nur daran liegen, dass reply-to nicht funktioniert.

Ja genau. Nehme ich den Haken bei "Don't pull routes" raus, funktioniert kein Ping, kein SSH usw. an die DMZ
Setzte ich ihn wieder , funktioniert ping usw.
Dafür geht im LAN nichts mehr
Also gehe ich von einem Routing Problem aus.

Wenn ich : tcpdump -i ovpnc1 -n auf der Firwall Shell mache, sehe ich das jede Menge Traffic auf ovpnc1 ankommt.

Überprüfen kannst du da mit Packet Capture. Funktioniert es nicht, gehen die Antwort-Pakete um WAN raus, entsprechend der Default-Route.
Wenn das so ist, stelle nochmals sicher, dass
- auf OpenVPN keine Pass-Regel aktiv ist.
- in Firewall: Settings: Advanced reply-to nicht deaktiviert ist.
- reply-to in den jeweiligen Firewall-Regeln am VPN_Leg Interface nicht deaktiviert ist (Advanced Features). Du könntest da auch versuchsweise explizit das VPN Gateway angeben.
- die Firewall-Regeln am VPN_Leg auch zutreffen, indem du das Logging aktivierst und es dann im Log überprüfst.

Habe ich gemacht >Firewall: Settings: Advanced > kein Haken drin
Keine Rules in OpenVPN
reply-to in den Rules von VPN_Leg stehen auf default

Aus dem Capture kann ich leider nicht erkennen wo es dann zum Problem kommt.

[viragomann]

Wenn ich : tcpdump -i ovpnc1 -n auf der Firwall Shell mache, sehe ich das jede Menge Traffic auf ovpnc1 ankommt.

"Eine Menge" ist ein vager Ausdruck, der nicht hilft, den Fehler einzugrenzen. Es geht um die entsprechenden Verbindungen.
Die DMZ Hosts nutzen schließlich auch die VPN für ausgehenden Traffic. Das kann auch eine Menge sein.

Wenn ein Client von außen auf deinen Webserver auf Port 443 zugreift, dann antwortet der Server vom Port 443. Daran ist zu erkennen, ob das Antwort-Paket auch am VPN Interface raus geht. Darum geht es.

Auch könntest du ein Capture am WAN machen, um festzustellen, ob die Pakete da raus gehen.

Oder du kannst feststellen, ob die FW-Regeln überhaupt angewandt werden, wie auch schon vorgeschlagen.
Und es gab noch weitere Vorschläge. Schöpfe die mal aus.

reply-to in den Rules von VPN_Leg stehen auf default

Hierzu hatte ich bspw. vorgeschlagen, das VPN Gateway da mal fix zu setzen. Etwa bei der Regel, die Zugriff auf Port 443 zulässt. Dann teste mal via HTTPS von außen.
Aber die Regel muss auch zutreffen, sonst bringt das auch nix. Daher musst du das erst überprüfen.

[fw115]

Hallo,

also irgendwie bin ich raus.(Edit: Im Sinne von: Keine Ahnung was ich noch machen soll)

Ich bin nicht in der Lage das richtig zu analysieren und den Fehler zu finden.
Grundsätzlich scheine ich ja in der richtigen Richtung unterwegs zu sein, mangels Wissen > Fail

Hier mal ein Capture auf WAN > VLAN132

No.    Time    Source    Destination    Protocol    Length    Info
1    0.000000    82.XX.XX.XX    195.8.XX.2    ICMP    98    Echo (ping) request  id=0x003a, seq=1/256, ttl=59 (no response found!)
2    1.002001    82.XX.XX.XX    195.8.xx.2    ICMP    98    Echo (ping) request  id=0x003a, seq=2/512, ttl=59 (no response found!)
3    2.025953    82.XX.XX.XX    195.8.xx.2      ICMP    98    Echo (ping) request  id=0x003a, seq=3/768, ttl=59 (no response found!)
4    10.708563    195.8.XX.XX    82.XX.XX.XX    ICMP    98    Echo (ping) reply    id=0x003b, seq=1/256, ttl=64
5    11.753931    195.8.XX.2    82.XX.XX.XX    ICMP    98    Echo (ping) reply    id=0x003b, seq=2/512, ttl=64
6    12.777972    195.8.XX.2    82.XX.XX.XX    ICMP    98    Echo (ping) reply    id=0x003b, seq=3/768, ttl=64
7    21.047062    195.8.XX.2    82.XX.XX.XX    ICMP    98    Echo (ping) reply    id=0x003c, seq=1/256, ttl=64
8    22.058254    195.8.XX.2    82.XX.XX.XX    ICMP    98    Echo (ping) reply    id=0x003c, seq=2/512, ttl=64
9    23.082249    195.8.XX.2    82.XX.XX.XX    ICMP    98    Echo (ping) reply    id=0x003c, seq=3/768, ttl=64

Ich habe von extern 82.xx auf den internen Host hinter dem DMZ Interface gepingt. Also die 2. Nutzbare IP aus dem /29 Netz.

Das oben ist die Antwort.

Wenn ich ein tcpdump -n -i ovpnc1 icmp mache, ist das die Antwort:

tcpdump -n -i ovpnc1 icmp
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on ovpnc1, link-type NULL (BSD loopback), snapshot length 262144 bytes

00:07:20.873096 IP 82.xx.xx.xx > 195.8.XX.2: ICMP echo request, id 68, seq 1, length 64
00:07:22.944518 IP 82.xx.xx.xx > 195.8.XX.2: ICMP echo request, id 68, seq 2, length 64
00:07:23.943687 IP 82.xx.xx.xx > 195.8.XX.2: ICMP echo request, id 68, seq 3, length 64
00:07:25.097888 IP 82.xx.xx.xx > 195.8.XX.2: ICMP echo request, id 68, seq 4, length 64
00:07:26.013077 IP 82.xx.xx.xx > 195.8.XX.2: ICMP echo request, id 68, seq 5, length 64
00:07:27.051476 IP 82.xx.xx.xx > 195.8.XX.2: ICMP echo request, id 68, seq 6, length 64
00:07:28.098145 IP 82.xx.xx.xx > 195.8.XX.2: ICMP echo request, id 68, seq 7, length 64
00:07:29.122337 IP 82.xx.xx.xx > 195.8.XX.2: ICMP echo request, id 68, seq 8, length 64

Meine Schlüsse daraus bisher:
Der VPN-Tunnel funktioniert
Der eingehende Verkehr ist korrekt
Keine Echo Replies sichtbar > der Antwortverkehr geht nicht über ovpnc1 zurück
Es kommt keine Antwort , egal was ich an Rules wo einstelle.

Ich habe keinen Plan was ich noch machen soll und wie.
Auch die feste Angabe in den Advanced Einstellungen der Rules hat keine Veränderung gebracht.
Eine feste Route hat auch nichts gebracht.
Ich habe mehr Fragen als ich mir selber Antworten geben kann.