OPNsense 26.1.6 – Destination NAT

Started by bts, April 10, 2026, 08:49:52 AM

Previous topic - Next topic
Hallo zusammen

ich habe seit OPNsense 26.1.6 ein Problem mit einer Konstellation, die früher mit einer einfachen Destination-NAT-Regel funktioniert hat.

Ausgangslage:
Die Anfrage kommt aus einem OpenVPN-Netz:

172.17.30.0/24

Ein Client aus diesem Netz greift auf folgende Adresse zu:

10.3.0.10:7000/tcp

Diese Anfrage soll per NAT wie folgt umgesetzt werden:

eingehend auf 10.3.0.10:7000/tcp
Weiterleitung intern auf 10.10.11.5:443/tcp

Ziel:**
Die Verbindung soll so umgesetzt werden, dass die Firewall als Absender erscheint, damit der interne Zielhost 10.10.11.5 das VPN-Netz 172.17.30.0/24 nicht kennen bzw. nicht routen muss.

Früher reichte dafür eine einfache Destination-NAT-Regel. Das scheint in dieser Form nicht mehr zu funktionieren.

Bisher versucht:

Port Forward / Destination NAT
zusätzlich Hybrid Outbound NAT
dort eine zusätzliche NAT-Regel, damit die Anfrage beim internen Ziel mit der Firewall als Source ankommt

Beobachtung:
Im Live Log sieht es so aus, als würde die Übersetzung greifen. Trotzdem öffnet sich die Webseite auf 10.10.11.5:443 nicht.

Frage:
Wie bildet man diese Konstellation unter OPNsense 26.1.6 korrekt ab?

Benötigt es inzwischen zwingend eine Kombination aus:

Port Forward / Destination NAT
Outbound NAT
passende Firewall-Regeln auf OpenVPN und LAN

oder hat sich bei der NAT-Verarbeitung etwas geändert?

Falls jemand so ein Szenario bereits umgesetzt hat, wäre ich für ein Beispiel dankbar.
Wichtig ist vor allem, dass der interne Host nicht direkt ins VPN-Netz zurückrouten muss, sondern die Firewall als Absender verwendet wird.

Vielen Dank

Hallo

Quote from: bts on April 10, 2026, 08:49:52 AMZiel:**
Die Verbindung soll so umgesetzt werden, dass die Firewall als Absender erscheint, damit der interne Zielhost 10.10.11.5 das VPN-Netz 172.17.30.0/24 nicht kennen bzw. nicht routen muss.

Früher reichte dafür eine einfache Destination-NAT-Regel. Das scheint in dieser Form nicht mehr zu funktionieren.
Nein. Destination NAT macht und machte keine Umsetzung der Source-Adresse. Dazu war eine Outbound NAT Regel nötig.

Also nach dem du sowohl Source- als auch Distination NAT machen möchtest benötigst du zwei Regeln, heute wie damals.
- Destination NAT am OpenVPN Interface
- Source NAT am Interface, an dem die Pakete zum Zielhost rausgehen.

Eine Firewall-Regel braucht es auch. Dafür gibt es nach wie vor im Destination NAT die Möglichkeit, im Destination NAT eine erstellen zu lassen, ist aber nicht mehr Default, oder einfach "pass" zu setzen.

Fürs korrekte Routing sollte es allerdings reichen, dass der Zielhost die OPNsense als Standardgateway nutzt.
Die Source-NAT Regel sollte dann nicht nötig sein.

Grüße

Quote from: viragomann on April 10, 2026, 02:48:32 PMEine Firewall-Regel braucht es auch. Dafür gibt es nach wie vor im Destination NAT die Möglichkeit, im Destination NAT eine erstellen zu lassen, ist aber nicht mehr Default, oder einfach "pass" zu setzen.
Wenn das früher Default war, liegt es wahrtscheinlich einfach daran. Aber
Quote from: viragomann on April 10, 2026, 02:48:32 PMFürs korrekte Routing sollte es allerdings reichen, dass der Zielhost die OPNsense als Standardgateway nutzt.
Die Source-NAT Regel sollte dann nicht nötig sein.
das sieht mir eher aus, als würde der Standardgateway fürs normale Internet via ISP-Router gebraucht und die Sensebox macht nur das VPN.