Hallo zusammen,
durch die Änderungen rund um Issue 8009 (https://github.com/opnsense/core/issues/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?