"Recent posts
#1
German - Deutsch / Kein DNAT auf lo0: tailscale a...
Last post by nexo - Today at 06:57:53 PMHallo zusammen,
durch die Änderungen rund um Issue 8009 werden DNAT-Regeln offenbar nicht mehr auf dem lo0-Interface berücksichtigt. Zusätzlich können DNAT-Regeln für lo0 wohl auch nicht mehr erstellt werden.
Das hat bei mir zur Folge, dass DNAT für ausgehende Verbindungen von der OPNsense selbst nicht mehr greift. Betroffen sind damit Dienste wie Tailscale, Git-Backup oder NextCloud-Backup zu intern gehosteten Nextcloud/Git/Headscale hinter einem Reverse Proxy.
Mein Setup:
Headscale läuft intern hinter einem Reverse Proxy.
Port 443 auf der WAN-Adresse wird per DNAT an den Reverse Proxy weitergeleitet (+ NAT-Reflect/Hairpin NAT z. B. für interne Clients im DMZ-Netz)
Externe und itnerne Tailscale-Clients können sich problemlos mit Headscale verbinden.
Auf der OPNsense selbst läuft ebenfalls ein Tailscale-Client, unter anderem um für andere Clients Routen zu advertisen und lokale Netzwerkresourcen bereitzustellen.
Das Problem:
Wenn der Tailscale-Client auf der OPNsense die Headscale/ReverseProxy-URL aufruft, löst diese auf die WAN-IP der OPNsense auf. Früher konnte das über DNAT auf lo0 zum Reverse Proxy umgebogen werden. Jetzt landet die Verbindung aber beim eingebauten OPNsense-Webserver statt beim Reverse Proxy bzw. Headscale.
Das gleiche Problem hätte ich vermutlich auch bei os-git-backup, wenn der Git-Server hinter demselben Reverse Proxy liegt, oder bei NextCloud-Backups zu einer intern gehosteten Nextcloud.
Mögliche Lösungen, die ich sehe:
1.) Split-DNS
1.1)
/etc/hosts-Eintrag auf der OPNsense
Funktioniert grundsätzlich - kurzfristig, wird aber überschrieben und ist daher keine saubere Lösung.
1.2)
Unbound DNS Override
Würde funktionieren, betrifft aber das ganze Netz und nicht nur die OPNsense. Außerdem ist das bei intenen Hosts welche DNSSEC verifizieren und vielen Hostnamen eher unschön.
1.3)
dnsmasq mit source-IP-basierten Overrides
Scheint technisch möglich zu sein, würde aber bedeuten, den Standard-DNS-Dienst auf der OPNsense umzustellen - nur für die OPNsense selbst. Für den Ersatz einer früher einfachen lo0-DNAT-Regel wirkt das recht aufwendig.
2.)
Eigene Subdomain nur für die OPNsense
Beispiel: headscale-opnsense.example.com zeigt direkt auf die interne Reverse-Proxy-IP.
Diese Domain würde ich nur z.B. im tailscale Dienst auf der OPNsense verwenden.
Nachteil: Für eine rein interne Auflösung ist kein normales Let's-Encrypt-Zertifikat möglich, außer man geht wieder über DNS-01-Challenge/Wildcard oder ähnliche Konstruktionen.
3.) Anderer lokaler Workaround
Bisher habe ich keinen wirklich sauberen gefunden.
Ich frage mich daher, was in dieser Situation die empfohlene oder sauberste Lösung ist.
Gibt es eine offensichtliche Möglichkeit, die ich übersehe?
Oder ist Split-DNS in diesem Fall tatsächlich der "richtige" Weg, obwohl es sich eher wie ein Hack anfühlt?
Wie löst ihr das?
durch die Änderungen rund um Issue 8009 werden DNAT-Regeln offenbar nicht mehr auf dem lo0-Interface berücksichtigt. Zusätzlich können DNAT-Regeln für lo0 wohl auch nicht mehr erstellt werden.
Das hat bei mir zur Folge, dass DNAT für ausgehende Verbindungen von der OPNsense selbst nicht mehr greift. Betroffen sind damit Dienste wie Tailscale, Git-Backup oder NextCloud-Backup zu intern gehosteten Nextcloud/Git/Headscale hinter einem Reverse Proxy.
Mein Setup:
Headscale läuft intern hinter einem Reverse Proxy.
Port 443 auf der WAN-Adresse wird per DNAT an den Reverse Proxy weitergeleitet (+ NAT-Reflect/Hairpin NAT z. B. für interne Clients im DMZ-Netz)
Externe und itnerne Tailscale-Clients können sich problemlos mit Headscale verbinden.
Auf der OPNsense selbst läuft ebenfalls ein Tailscale-Client, unter anderem um für andere Clients Routen zu advertisen und lokale Netzwerkresourcen bereitzustellen.
Das Problem:
Wenn der Tailscale-Client auf der OPNsense die Headscale/ReverseProxy-URL aufruft, löst diese auf die WAN-IP der OPNsense auf. Früher konnte das über DNAT auf lo0 zum Reverse Proxy umgebogen werden. Jetzt landet die Verbindung aber beim eingebauten OPNsense-Webserver statt beim Reverse Proxy bzw. Headscale.
Das gleiche Problem hätte ich vermutlich auch bei os-git-backup, wenn der Git-Server hinter demselben Reverse Proxy liegt, oder bei NextCloud-Backups zu einer intern gehosteten Nextcloud.
Mögliche Lösungen, die ich sehe:
1.) Split-DNS
1.1)
/etc/hosts-Eintrag auf der OPNsense
Funktioniert grundsätzlich - kurzfristig, wird aber überschrieben und ist daher keine saubere Lösung.
1.2)
Unbound DNS Override
Würde funktionieren, betrifft aber das ganze Netz und nicht nur die OPNsense. Außerdem ist das bei intenen Hosts welche DNSSEC verifizieren und vielen Hostnamen eher unschön.
1.3)
dnsmasq mit source-IP-basierten Overrides
Scheint technisch möglich zu sein, würde aber bedeuten, den Standard-DNS-Dienst auf der OPNsense umzustellen - nur für die OPNsense selbst. Für den Ersatz einer früher einfachen lo0-DNAT-Regel wirkt das recht aufwendig.
2.)
Eigene Subdomain nur für die OPNsense
Beispiel: headscale-opnsense.example.com zeigt direkt auf die interne Reverse-Proxy-IP.
Diese Domain würde ich nur z.B. im tailscale Dienst auf der OPNsense verwenden.
Nachteil: Für eine rein interne Auflösung ist kein normales Let's-Encrypt-Zertifikat möglich, außer man geht wieder über DNS-01-Challenge/Wildcard oder ähnliche Konstruktionen.
3.) Anderer lokaler Workaround
Bisher habe ich keinen wirklich sauberen gefunden.
Ich frage mich daher, was in dieser Situation die empfohlene oder sauberste Lösung ist.
Gibt es eine offensichtliche Möglichkeit, die ich übersehe?
Oder ist Split-DNS in diesem Fall tatsächlich der "richtige" Weg, obwohl es sich eher wie ein Hack anfühlt?
Wie löst ihr das?
#2
Intrusion Detection and Prevention / Re: Should I block outbound tr...
Last post by crc - Today at 06:47:08 PMGenerally speaking (not specific to OpnSense, @Vilhonator pointed to the OpnSense specific configuration manual entry) - when you're running public-facing services, you want to also take in consideration what's leaving your server (as a best rule practice, and part of the defense in depth strategy). Sometimes and for specific scenarios, a drop-all on both ingress and egress sides (while allowing only necessary inbound and outbound connections) is the best strategy, although it takes time and patience to configure correctly (and even so it might not protect you against data exfiltration via not blocked protocols, such as DNS). If you have an exposed web service, perhaps a waf of some sort (modsecurity, coraza, or the more expensive commercial ones) would help in addition to a firewall.
#3
26.1, 26,4 Series / Fatal error: Uncaught TypeErro...
Last post by RolandR - Today at 06:35:54 PMSince the update to OPNsense 26.1.8_5 (amd64) I get the following error, Does anyone now how to fix this?
I just updated to the latest packages/version and since then it stops booting at this point.
Thanks for any hints on this.
Roland
I just updated to the latest packages/version and since then it stops booting at this point.
Code Select
Generating /etc/resolv.conf...
Fatal error: Uncaught TypeError: OPNsense\Firewall\Util::getRealInterface():
Argument #1 ($interface) must be of type string, null given, called in /usr/local/opnsense/mvc/app/models/OPNsense/Routing/Gateways.php on line 367 and defined in /usr/local/opnsense/mvc/app/library/OPNsense/Firewall/Util.php:686
Stack trace:
#0 /usr/local/opnsense/mvc/app/models/OPNsense/Routing/Gateways.php(367): OPNsense\Firewall\Util::getRealInterface(NULL, 'inet')
#1 /usr/local/opnsense/mvc/app/models/OPNsense/Routing/Gateways.php(517): OPNsense\Routing\Gateways->getGateways()
#2 /usr/local/etc/inc/plugins.inc.d/dpinger.inc(111): OPNsense\Routing\Gateways->gatewaysIndexedByName()
#3 /usr/local/etc/inc/plugins.inc.d/dpinger.inc(38): dpinger_instances()
#4 /usr/local/etc/inc/plugins.inc(81): dpinger_services()
#5 /usr/local/etc/inc/util.inc(116): plugins_services()
#6 /usr/local/etc/inc/util.inc(111): service_by_name('*', Array)
#7 /usr/local/etc/inc/system.inc(212): service_by_filter(Array)
#8 /usr/local/etc/inc/system.inc(511): system_resolvconf_generate(true)
#9 /usr/local/etc/rc.bootup(85): system_resolver_configure(true)Thanks for any hints on this.
Roland
#4
26.1, 26,4 Series / Re: Transparent Bridging Firew...
Last post by crc - Today at 06:10:11 PMAs other people have mentioned, it's hard to guess without knowing your exact configuration and topology. Can you share with us a network diagram and/or screenshots of the current configuration (sans sensitive information of course)? Having a router behind a firewall does not necessarily mean that you have to NAT something on the firewall itself so you can avoid double NAT if the ONT is in bridge mode as you stated.
Conversely, you might want the OpnSense firewall to also act as the main router and set up the Google mesh in AP/bridge mode. This would entail configuring the client side (pppoe client, dhcp client, static ip, whatever your provider offers) on the OpnSense device. I've successfully had TpLink Decos behind an OpnSense firewall sitting on an industrial 4-port Ethernet mini-PC and it worked perfectly.
Conversely, you might want the OpnSense firewall to also act as the main router and set up the Google mesh in AP/bridge mode. This would entail configuring the client side (pppoe client, dhcp client, static ip, whatever your provider offers) on the OpnSense device. I've successfully had TpLink Decos behind an OpnSense firewall sitting on an industrial 4-port Ethernet mini-PC and it worked perfectly.
#5
General Discussion / Re: How can I minimise latency...
Last post by meyergru - Today at 05:48:53 PM1. no
2. yes
3. yes, no need to worry
2. yes
3. yes, no need to worry
#6
General Discussion / Re: How can I minimise latency...
Last post by hushcoden - Today at 05:28:56 PMOkay, I'll try this evening, thanks.
P.S.
1. should I consider to shape the WAN upload only or also WAN download?
2. although the PS5 is on a different subnet, in the section 'source' of the rule the default value is "any" so that covers all the networks, right?
3. this setup covers everything leaving WAN, including VPN traffic which I have on another port (LAN2), and I suppose it's perfectly fine, no need to worry ?
P.S.
1. should I consider to shape the WAN upload only or also WAN download?
2. although the PS5 is on a different subnet, in the section 'source' of the rule the default value is "any" so that covers all the networks, right?
3. this setup covers everything leaving WAN, including VPN traffic which I have on another port (LAN2), and I suppose it's perfectly fine, no need to worry ?
#7
German - Deutsch / Re: OPNCentral enteuschung
Last post by ews - Today at 05:14:56 PMIch glaube du hast keine Option übersehen — das ist tatsächlich ziemlich nah an dem aktuellen Stand von OPNCentral.
Die Plattform entwickelt sich zwar sichtbar weiter und mit 26.4 wurde ja begonnen, Firewall-Regeln auf das neue MVC/API-System umzustellen, aber im Moment ist OPNCentral noch eher ,,zentralisierte Konfigurationsverteilung" als echtes zentrales Management wie man es z.B. von FortiManager, Panorama oder Sophos Central kennt.
Gerade bei heterogenen Umgebungen mit:
unterschiedlichen VLANs
zusätzlichen WireGuard/OpenVPN-Tunneln
abweichenden Interface-Layouts
standortspezifischen Regeln
stößt das Konzept aktuell sehr schnell an Grenzen.
Das Hauptproblem ist genau das was du beschrieben hast:
die Zuordnung basiert intern stark auf der Reihenfolge bzw. den generierten Interface-IDs (opt1/opt2 usw.) und nicht auf stabilen frei definierbaren Interface-Objekten. Dadurch funktioniert das Ganze praktisch nur wirklich zuverlässig wenn die Firewalls nahezu identisch aufgebaut sind.
Ich glaube aber auch, dass OPNsense das durchaus bewusst ist. Wenn man sich die Entwicklung der letzten Versionen anschaut, sieht man schon klar die Richtung:
Migration auf MVC/API
neue zentrale Rule-Engine
immer mehr API-fähige Komponenten
OPNCentral-Ausbau
automatische Host-Erkennung
zentralisierte Verwaltungsidee
Aber aktuell steckt das Ganze technisch noch mitten im Umbau.
Für identische Außenstellen (wie bei uns) funktioniert OPNCentral heute schon durchaus brauchbar.
Für echte Multi-Site-Umgebungen mit individuellen Standorten fehlt aber aus meiner Sicht noch:
stabile Interface-UUIDs
Mapping nach Namen statt Reihenfolge
Template-/Variablen-System
Merge statt Replace
standortspezifische Overrides
Erst dann wird daraus wirklich ,,zentrale Verwaltung" und nicht eher eine intelligente 1:1 der config.xml.
Die Plattform entwickelt sich zwar sichtbar weiter und mit 26.4 wurde ja begonnen, Firewall-Regeln auf das neue MVC/API-System umzustellen, aber im Moment ist OPNCentral noch eher ,,zentralisierte Konfigurationsverteilung" als echtes zentrales Management wie man es z.B. von FortiManager, Panorama oder Sophos Central kennt.
Gerade bei heterogenen Umgebungen mit:
unterschiedlichen VLANs
zusätzlichen WireGuard/OpenVPN-Tunneln
abweichenden Interface-Layouts
standortspezifischen Regeln
stößt das Konzept aktuell sehr schnell an Grenzen.
Das Hauptproblem ist genau das was du beschrieben hast:
die Zuordnung basiert intern stark auf der Reihenfolge bzw. den generierten Interface-IDs (opt1/opt2 usw.) und nicht auf stabilen frei definierbaren Interface-Objekten. Dadurch funktioniert das Ganze praktisch nur wirklich zuverlässig wenn die Firewalls nahezu identisch aufgebaut sind.
Ich glaube aber auch, dass OPNsense das durchaus bewusst ist. Wenn man sich die Entwicklung der letzten Versionen anschaut, sieht man schon klar die Richtung:
Migration auf MVC/API
neue zentrale Rule-Engine
immer mehr API-fähige Komponenten
OPNCentral-Ausbau
automatische Host-Erkennung
zentralisierte Verwaltungsidee
Aber aktuell steckt das Ganze technisch noch mitten im Umbau.
Für identische Außenstellen (wie bei uns) funktioniert OPNCentral heute schon durchaus brauchbar.
Für echte Multi-Site-Umgebungen mit individuellen Standorten fehlt aber aus meiner Sicht noch:
stabile Interface-UUIDs
Mapping nach Namen statt Reihenfolge
Template-/Variablen-System
Merge statt Replace
standortspezifische Overrides
Erst dann wird daraus wirklich ,,zentrale Verwaltung" und nicht eher eine intelligente 1:1 der config.xml.
#8
Intrusion Detection and Prevention / Re: Should I block outbound tr...
Last post by Vilhonator - Today at 03:29:39 PMNo. You create same rule on LAN network (source is Lan network and destination are aliases you created, rest are the same).
https://docs.opnsense.org/manual/how-tos/drop.html
https://docs.opnsense.org/manual/how-tos/drop.html
#9
26.1, 26,4 Series / Re: OPNcentral NAT sync crash ...
Last post by franco - Today at 02:36:33 PMThank you, still working on it.
Cheers,
Franco
Cheers,
Franco
#10
26.1, 26,4 Series / Re: Transparent Bridging Firew...
Last post by Nullman - Today at 02:35:54 PMAnd also, if your ISP modem is in bridge mode, you dont have double NAT.
