21
OPNsense - Verständnisfrage zu Gateways
Hallo zusammen,
für ein privates Projekt habe ich eine Firewall mit OPNsense aufgesetzt. Natürlich auf dem neusten Versionsstand (23.7.8_1-amd64). Grundlage für meine Konfiguration ist der Artikel WireGuard Selective Routing to External VPN Endpoint .
Damit konnte ich problemlos einen Wireguard VPN Tunnel zu meinem Bruder aufbauen. Den Schritt 11 aus dem Link haben wir überspringen. Die Geräte melden sich dort bei einem Controller und nutzen dort auch den Internetzugang. Grundsätzlich funktioniert der Aufbau wie es geplant war.
Nun kommt es immer wieder vor, dass der VPN Tunnel unterbrochen ist. Die Ursachen dafür sind vielfältig (Firewall Update, Probleme beim ISP, etc.). Daher habe ich auf den beiden WG Gateways (IPv4 & IPv6) jeweils Monitor IP hinterlegt.
Ist die Monitor IP nicht mehr erreichbar, wechselt der Status der beiden VPN Gateways in wenigen Sekunden von "Online" zu "Offline".
Laut dem Parameter "Gateway Monitoring -> Skip rules" sollte anstatt dem konfigurierte Gateway in der zutreffenden Firewall Regel, das Default Gateway verwendet werden.
Ist die VPN Verbindung nicht aufgebaut bzw. die beiden Gateways wie im letzten Screenshot "offline" markiert, sollten meinem Verständnis nach meine IoT Geräte über meine Firewall ins Internet kommen. Tun sie aber nicht.
Erst wenn die beiden Gateways manuell deaktiviere, die Änderung speichere und es nochmals das IoT Gerät neu starte, hat das Gerät Internetzugriff.
Was habe ich bereits untersucht:
Weshalb "schickt" die OPNsense, wenn der Tunnel down ist und die Gateways "offline sind," die IoT Geräte nicht direkt ins Internet? Wo ist mein Verständnis- bzw. Konfigurationsproblem?
Gruß,
Dani
für ein privates Projekt habe ich eine Firewall mit OPNsense aufgesetzt. Natürlich auf dem neusten Versionsstand (23.7.8_1-amd64). Grundlage für meine Konfiguration ist der Artikel WireGuard Selective Routing to External VPN Endpoint .
Damit konnte ich problemlos einen Wireguard VPN Tunnel zu meinem Bruder aufbauen. Den Schritt 11 aus dem Link haben wir überspringen. Die Geräte melden sich dort bei einem Controller und nutzen dort auch den Internetzugang. Grundsätzlich funktioniert der Aufbau wie es geplant war.
Nun kommt es immer wieder vor, dass der VPN Tunnel unterbrochen ist. Die Ursachen dafür sind vielfältig (Firewall Update, Probleme beim ISP, etc.). Daher habe ich auf den beiden WG Gateways (IPv4 & IPv6) jeweils Monitor IP hinterlegt.
Ist die Monitor IP nicht mehr erreichbar, wechselt der Status der beiden VPN Gateways in wenigen Sekunden von "Online" zu "Offline".
Laut dem Parameter "Gateway Monitoring -> Skip rules" sollte anstatt dem konfigurierte Gateway in der zutreffenden Firewall Regel, das Default Gateway verwendet werden.
By default, when a rule has a specific gateway set, and this gateway is down, rule is created and traffic is sent to default gateway. This option overrides that behavior and the rule is not created when gateway is down
Ist die VPN Verbindung nicht aufgebaut bzw. die beiden Gateways wie im letzten Screenshot "offline" markiert, sollten meinem Verständnis nach meine IoT Geräte über meine Firewall ins Internet kommen. Tun sie aber nicht.
Erst wenn die beiden Gateways manuell deaktiviere, die Änderung speichere und es nochmals das IoT Gerät neu starte, hat das Gerät Internetzugriff.
Was habe ich bereits untersucht:
- Im GitHub Project die Issues durchgeschaut, die evtl. auf einen Bug hindeuten -> nichts gefunden
- In den Einstellungen der Gateways, Parameter "Mark Gateway as Down" den Haken gesetzt, um zu sehen ob das einen Unterschied macht -> Nein. Das Fehlerbild ist unverändert.
- Die Firewall Regeln an sich habe ich ausgeschlossen, da es mit deaktivieren Gateways vom WG Tunnel der direkte Internetzugriff funktioniert.
Weshalb "schickt" die OPNsense, wenn der Tunnel down ist und die Gateways "offline sind," die IoT Geräte nicht direkt ins Internet? Wo ist mein Verständnis- bzw. Konfigurationsproblem?
Gruß,
Dani
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 73915348673
Url: https://administrator.de/contentid/73915348673
Printed on: April 27, 2024 at 11:04 o'clock
21 Comments
Latest comment
Hi Dani,
das Problem ist der Wireguard-Tunnel, der sich eigentlich nach einem Ausfall der Internetverbindung wieder automatisch aufbauen sollte.
Hier kommt wohl das Problem der Zwangstrennung des Providers zum tragen.
Ob Du den Tunnel stabil bekommst, hängt davon ab, welchen Anschluß Dein Provider, bzw. der Deines Bruders bereitstellt.
Ohne feste IP vom Provider, ist Wiregard häufig nicht die beste Wahl.
Gruß orcape
das Problem ist der Wireguard-Tunnel, der sich eigentlich nach einem Ausfall der Internetverbindung wieder automatisch aufbauen sollte.
Hier kommt wohl das Problem der Zwangstrennung des Providers zum tragen.
Ob Du den Tunnel stabil bekommst, hängt davon ab, welchen Anschluß Dein Provider, bzw. der Deines Bruders bereitstellt.
Ohne feste IP vom Provider, ist Wiregard häufig nicht die beste Wahl.
Gruß orcape
Entscheident ist auch wie man das Routing eingestellt hat bei der OPNsense. Diese bietet, im Gegensatz zur pfSense, im Setup das Ein- bzw. Abschalten des Cryptokey Routings.
Ist es abgeschaltet, wie z.B. bei der pfSense und auch Mikrotik, dann muss man zwingend das interne WG Gateway und statische Route ins remote Netz konfigurieren da die FW es nicht automatisch lernt.
Entspricht dem Aktivieren vom IP Forwarding unter Windows, Linux, MacOS.
Der WG VPN Initiator (Client) sollte zwingend einen 25 Sek. UDP Keepalive aktiv haben um auf der Gegenseite den UDP Port in der Firewall aufzuhalten sofern man den Tunnel permanent halten will. Andernfalls timed diese ohne relevanten Traffic nach 30-60 Sekunden aus und der Tunnel wird dann nur wieder neu aufgebaut wenn wieder relevanter Traffic vom Client kommt.
Alles hängt also vom genauen Setup ab was wir nicht kennen.
Die genauen Schritte sind im Wireguard Tutorial für die OPNsense aufgelistet.
Tricky wird es immer wenn DDNS bei einem Dual Stack primär auf eine IPv6 Adresse auflöst das WG Setup aber nur für v4 konfiguriert ist. In der Regel rennt das mit DDNS auf dem VPN Initiator fehlerfrei sofern der DDNS Dienst für v4 oder v6 auch fehler- und einigermaßen verzögerungsfrei rennt.
Entspricht dem Aktivieren vom IP Forwarding unter Windows, Linux, MacOS.
Der WG VPN Initiator (Client) sollte zwingend einen 25 Sek. UDP Keepalive aktiv haben um auf der Gegenseite den UDP Port in der Firewall aufzuhalten sofern man den Tunnel permanent halten will. Andernfalls timed diese ohne relevanten Traffic nach 30-60 Sekunden aus und der Tunnel wird dann nur wieder neu aufgebaut wenn wieder relevanter Traffic vom Client kommt.
Alles hängt also vom genauen Setup ab was wir nicht kennen.
Die genauen Schritte sind im Wireguard Tutorial für die OPNsense aufgelistet.
Ohne feste IP vom Provider, ist Wiregard häufig nicht die beste Wahl.
IP v4 oder v6?? Das kann man so pauschal nicht sagen.Tricky wird es immer wenn DDNS bei einem Dual Stack primär auf eine IPv6 Adresse auflöst das WG Setup aber nur für v4 konfiguriert ist. In der Regel rennt das mit DDNS auf dem VPN Initiator fehlerfrei sofern der DDNS Dienst für v4 oder v6 auch fehler- und einigermaßen verzögerungsfrei rennt.
Moin @orcape,
es ist nicht die Frage, weshalb der WG Tunnel temporär nicht verfügbar ist. Meine Frage ist, weshalb meine OPNsense den Traffic meiner IoT Geräte nicht direkt ins Internet routet, wenn die Gateways des WG Tunnel als "Offline" markiert sind.
Gruß,
Dani
es ist nicht die Frage, weshalb der WG Tunnel temporär nicht verfügbar ist. Meine Frage ist, weshalb meine OPNsense den Traffic meiner IoT Geräte nicht direkt ins Internet routet, wenn die Gateways des WG Tunnel als "Offline" markiert sind.
Gruß,
Dani
Moin @aqui,
ich habe mich an den von mir verlinkten Artikel gehalten (Step 2). D.h. der Parameter "Disable routes" ist bereits deaktiviert. Anderenfalls würde meine OPNsense sämtlichen Traffic meines ganzen Heim-Netzwerks in den WG Tunnel schicken.
)
Gruß,
Dani
ich habe mich an den von mir verlinkten Artikel gehalten (Step 2). D.h. der Parameter "Disable routes" ist bereits deaktiviert. Anderenfalls würde meine OPNsense sämtlichen Traffic meines ganzen Heim-Netzwerks in den WG Tunnel schicken.
Der WG VPN Initiator (Client) sollte zwingend einen 25 Sek. UDP Keepalive aktiv haben um auf der Gegenseite den UDP Port in der Firewall aufzuhalten. Andernfalls timed der 30-60 Sekunden aus und der Tunnel wird dann nur wieder neu aufgebaut wenn relevanter Traffic vom Client kommt.
Die 25 Sekunden sind in der WG Tunnel Konfiguration bereits hinterlegt (Step 1 im verlinkten Artikel )Gruß,
Dani
weshalb meine OPNsense den Traffic meiner IoT Geräte nicht direkt ins Internet routet, wenn die Gateways des WG Tunnel
Das sollten sie immer solange du eine klassische Split Tunneling Konfig auf der OPNsense betreibst und KEIN Redirect Setup. Andernfalls ist es vermutlich ein Konfig Fehler.
Moin @aqui,
Nachstehend zwei Screenshots meiner WG Konfiguration:
Nachstehend ein Screenshot der Firewall Rule:
Was fällt dir noch an möglichen Ursachen ein?
Gruß,
Dani
Andernfalls ist es vermutlich ein Konfig Fehler.
folgende Punkte habe ich ausgeschlossen:- An einem "Kill Switch" kann es nicht liegen. Step 11 aus meinen Link habe ich nicht umgesetzt.
- Der Parameter "Disable routes" ist in der Konfiguration der WG Instance aktiviert. Anderenfalls würde sämtlicher Traffic von allen meinen VLANs in den Tunnel geschickt?!
- Ich hab eine auf dem VLAN Interface eine Firewall Regel. Dort habe ich als Gateway das virtuelle Interface des WG Tunnels hinterlegt. Anderenfalls würde die Daten nicht in den Tunnel geschickt.
- Die NAT Outbound Regeln habe ich ausgeschlossen. Anderenfalls würde weder der Internetzugriff über den WG Tunnel noch bei deaktivierten Gateways nicht problemlos funktionieren.
- Der Parameter "Gateway switching" (System -> Settings-> General) ist nicht angehakt. Da ich den Parameter "Disable routes" aktiviert habe, spielt diese Option aus meiner Sicht keine Rolle. Somit gibt es nach wie vor nur eine IPv4 und Ipv6 Default Route. Nämlich die über meinen ISP.
Nachstehend zwei Screenshots meiner WG Konfiguration:
Nachstehend ein Screenshot der Firewall Rule:
Was fällt dir noch an möglichen Ursachen ein?
Gruß,
Dani
Hi
Du hast ::/0 in den AllowedIPs stehen, haben den deine Clients im VLAN eine öffentlich Routbare IPv6 aus dem Remote-Netz? Denn wenn nicht versuchen sie dann mit einer IPv6-Adresse des lokalen Netzes über den Tunnel ins Internet zu routen, was natürlich fehl schlägt. Also entweder ::/0 raus nehmen oder IPv6 Traffic auf die WG-Tunnel IPv6 Masqueraden.
Gruß Katrin
Du hast ::/0 in den AllowedIPs stehen, haben den deine Clients im VLAN eine öffentlich Routbare IPv6 aus dem Remote-Netz? Denn wenn nicht versuchen sie dann mit einer IPv6-Adresse des lokalen Netzes über den Tunnel ins Internet zu routen, was natürlich fehl schlägt. Also entweder ::/0 raus nehmen oder IPv6 Traffic auf die WG-Tunnel IPv6 Masqueraden.
Gruß Katrin
Moin @8030021182
Gruß,
Dani
haben den deine Clients im VLAN eine öffentlich Routbare IPv6 aus dem Remote-Netz?
Nein, die IoT Geräte haben ausschließlich IPv4 Adressen.Denn wenn nicht versuchen sie dann mit einer IPv6-Adresse des lokalen Netzes über den Tunnel ins Internet zu routen, was natürlich fehl schlägt.
Aktuell kommen die IoT Clients über den WG Tunnel zu dem besagten Controller und über den selben Weg auch ins Internet. Was auch dem Plan entspricht.Gruß,
Dani
Anderenfalls würde sämtlicher Traffic von allen meinen VLANs in den Tunnel geschickt?!
Nein, gar kein Traffic!! 
Aller Traffic würde nur mit einem Redirect 0.0.0.0/0 unter den Allowed IPs in den Tunnel gehen. Cryptokey Routing bei WG... Siehe zu der Thematik auch hier.Dort habe ich als Gateway das virtuelle Interface des WG Tunnels hinterlegt.
OK, wenn das automatische Kryptokey Routing deaktiviert ist musst du alles statisch setzen.Das Gateway wäre mit aktiviertem WG Routing in der OPNsense gar nicht erforderlich, denn das lernt sie ja durch das Cryptokey Routing dann dynamisch.
An den Default NAT Regeln muss man auch gar nichts rumfummeln und kann sie so belassen wie sie sind. Ebenso das Gateway Switching.
Dein Kardinalsfehler ist das du eine Redirect Konfig aufgesetzt hast statt ein sauberes Split Tunneling.
Hallo @aqui,
nach einer ruhigen Geschäftsreise holt mich die Realität wieder ein.
Wenn das VPN Gateway auf der OPNsense Offline ist (gewollt oder ungewollt), sollte doch der Datenverkehr der IoT Geräte zu einem Endpunkt im Internet über das Default Gateway meiner OPNsense geschickt werden. Was aber nicht geschieht. Das Kryptokey Routing sollte doch an dieser Stelle keine Rolle spielen?
Gruß,
Dani
nach einer ruhigen Geschäftsreise holt mich die Realität wieder ein.
Wenn das VPN Gateway auf der OPNsense Offline ist (gewollt oder ungewollt), sollte doch der Datenverkehr der IoT Geräte zu einem Endpunkt im Internet über das Default Gateway meiner OPNsense geschickt werden. Was aber nicht geschieht. Das Kryptokey Routing sollte doch an dieser Stelle keine Rolle spielen?
Gruß,
Dani
Würde das gleich über Gateway-Groups mit Failover machen
https://docs.opnsense.org/manual/multiwan.html
https://docs.opnsense.org/manual/how-tos/multiwan.html
Klappt hier im Test einwandfrei, mit einem angelegten Wireguard Tunnel.
https://docs.opnsense.org/manual/multiwan.html
https://docs.opnsense.org/manual/how-tos/multiwan.html
Klappt hier im Test einwandfrei, mit einem angelegten Wireguard Tunnel.
1sollte doch der Datenverkehr der IoT Geräte zu einem Endpunkt im Internet
Das ist zweifelsohne richtig. Wenn der Tunnel tot ist ist auch die Gateway Redirection außer Funktion.Bei der OPNsense ist das Cryptokey Routing aber individuell einstellbar ob man es dynamisch haben möchte oder gar kein dynamisches WG Routing. Da muss man also etwas aufpassen. (Bei der pfSense ist es immer aus und gar nicht konfigurierbar)
Das Kryptokey Routing sollte doch an dieser Stelle keine Rolle spielen?
Ja, wenn der Tunnel inaktiv ist spielt es keine Rolle. Wenn er aktiv ist und das dynamische WG Routing ebenso aber schon! Die Lösung des Kollegen @8030021182 ist etwas sauberer.
Hey endlich darf ich auch mal ein Mann sein 😀 💪 😎
2
Wenn es das denn nun war bitte deinen Thread dann auch als erledigt markieren!
How can I mark a post as solved?
How can I mark a post as solved?
Moin,
ich bin noch nicht dazu gekommen den Vorschlag (ausführlich) zu testen, da ich noch beruflich unterwegs bin. Wenn es gut geht, nächste Woche.
Gruß,
dani
ich bin noch nicht dazu gekommen den Vorschlag (ausführlich) zu testen, da ich noch beruflich unterwegs bin. Wenn es gut geht, nächste Woche.
Gruß,
dani
Zitat von @8030021182:
Würde das gleich über Gateway-Groups mit Failover machen
Klappt hier im Test einwandfrei, mit einem angelegten Wireguard Tunnel.
Mit einer Gateway Group lässt sich das Vorhaben umsetzen. Es funktioniert wie es soll. Danke dir.Würde das gleich über Gateway-Groups mit Failover machen
Klappt hier im Test einwandfrei, mit einem angelegten Wireguard Tunnel.
Nichts desto trotz werde ich mal die Entwickler fragen. Weil bei ein paar Regeln ist der Konfigurationsaufwand überschaubar. Aber wenn ich 20, 30 Regeln habe ist das doch ein vermeidbarer Aufwand. Zumal der dokumentierte Fallback nicht zu funktionieren scheint...
Herzliches Dank für eure Zeit und Nerven!
Gruß,
Dani
Ich meine mich auch noch zu erinnern das es unter Settings General noch eine Einstellung bezüglich Gateway Fallback gibt die man aktivieren muss damit deine Variante auch funktioniert, musst du selbst mal reinachauen, habe gerade kein Zugriff auf eine OPNSense.
Moin @8030021182
die Unterschiede zwischen pfSense und OPNsense gehen immer wieder auseinander. Für die OPNsense bin ich auf diesen Parameter aufmerksam geworden auf den ich mich auch beziehe:
Unter "System: Settings: General" gibt folgenden Parameter:
Ist aus meiner Sicht für mich nicht relevant, da das Default Gateway meine Internetverbindung ist und auch kein Multi WAN existiert. Seht ihr das genauso?
Gruß,
Dani
die Unterschiede zwischen pfSense und OPNsense gehen immer wieder auseinander. Für die OPNsense bin ich auf diesen Parameter aufmerksam geworden auf den ich mich auch beziehe:
Unter "System: Settings: General" gibt folgenden Parameter:
Ist aus meiner Sicht für mich nicht relevant, da das Default Gateway meine Internetverbindung ist und auch kein Multi WAN existiert. Seht ihr das genauso?
Gruß,
Dani
Zitat von @Dani:
Unter "System: Settings: General" gibt folgenden Parameter:
Ist aus meiner Sicht für mich nicht relevant, da das Default Gateway meine Internetverbindung ist und auch kein Multi WAN existiert. Seht ihr das genauso?
Auf den ersten Blick und der Beschreibung nach ja, aber Studieren geht bekanntlich über probieren 🤗, kann ja sein das die im Background auch das Switching über die FW-Regeln mit dran hängt. Also mal setzen und nochmal testen.Unter "System: Settings: General" gibt folgenden Parameter:
Ist aus meiner Sicht für mich nicht relevant, da das Default Gateway meine Internetverbindung ist und auch kein Multi WAN existiert. Seht ihr das genauso?
1
Moin,
Gruß,
Dani
Also mal setzen und nochmal testen.
das habe ich natürlich bereits ausprobiert, bevor ich den Beitrag hier verfasst habe. Brachte auch nicht den gewünschten Effekt. Im OPNsense Forum gibt es einen ähnlichen Beitrag von 2019. Allerding wurde das Problem laut den Antworten gefixt.Gruß,
Dani
Hast du die Option "Sticky Connections" deaktiviert? Hier klappt es aber auch nur zuverlässig über Gateway Groups.
1