OPNsense - NAT und Portweiterleitungen
Auf einen Blick
| Gilt für | OPNsense 26.1 und 26.7 (Firewall → NAT: Source NAT, Destination NAT, One-to-One NAT, NPTv6) |
|---|---|
| Bereich | IT-Security |
| Dauer | ca. 20 Minuten (Portweiterleitung + Source-NAT-Regel) |
| Rechte | Administrator (OPNsense-WebUI) |
| Stand | Oktober 2026 (OPNsense 26.7.5) |
NAT in OPNsense (Network Address Translation) übersetzt IP-Adressen und Ports beim Übergang zwischen Netzen: Interne Clients surfen mit der öffentlichen Adresse der Firewall ins Internet (Source NAT), Dienste im internen Netz werden per Portweiterleitung von außen erreichbar (Destination NAT), ganze Adressen oder Netze werden eins zu eins abgebildet (One-to-One NAT) und IPv6-Präfixe übersetzt (NPTv6). Seit OPNsense 26.x sind alle NAT-Arten auf eine einheitliche, moderne Oberfläche unter Firewall → NAT umgezogen.
Dieser Artikel erklärt die NAT-Arten in OPNsense 26.7, die Modi von Source NAT, Portweiterleitungen mit Firewall-Regeln, NAT Reflection, 1:1-NAT, NPTv6, die Migration alter Outbound-NAT-Regeln sowie typische Fehler.
NAT-Arten im Überblick
| Menüpunkt | Funktion | Typischer Einsatz |
|---|---|---|
| Source NAT (früher „Outbound NAT“) | ändert die Absender-Adresse ausgehender Pakete | Internetzugang für private Netze, ausgehende Adresse bei mehreren öffentlichen IPs, NAT über VPN-Tunnel |
| Destination NAT (früher „Port Forward“) | ändert die Ziel-Adresse/den Ziel-Port eingehender Pakete | Portweiterleitung zu Webserver, Mailserver, VoIP-Anlage |
| One-to-One NAT | bildet eine öffentliche Adresse fest auf eine interne ab (in beide Richtungen) | Server mit eigener öffentlicher IP, Überlappungen bei Standortkopplungen |
| NPTv6 | übersetzt IPv6-Präfixe 1:1 (RFC 6296) | IPv6 mit wechselndem Provider-Präfix oder Multi-WAN |
Alle Regel-Seiten bieten Kategorien, Sortierung, Protokollierung, eine Änderungshistorie (Audit mit Benutzer, Zeit und Notiz) und können Einträge per No XMLRPC Sync von der HA-Synchronisation ausnehmen.
Source NAT
Modi
Firewall → NAT → Source NAT – der Modus legt fest, wie Regeln entstehen:
| Modus | Verhalten | Empfehlung |
|---|---|---|
| Automatic (Standard) | OPNsense erzeugt Regeln für alle internen Netze auf jede WAN-Schnittstelle mit Gateway; eigene Regeln werden nicht ausgewertet | einfache Installationen |
| Hybrid | automatische Regeln plus eigene Regeln (eigene werden zuerst ausgewertet) | häufigste Wahl – Ergänzungen ohne Verlust der Automatik |
| Manual | nur eigene Regeln | volle Kontrolle, z. B. im HA-Cluster mit CARP-Adressen |
| Disabled | kein Source NAT | reine Router-Szenarien mit öffentlichen Adressen im LAN |
Eigene Source-NAT-Regel
Wichtige Felder einer Regel:
| Feld | Beispiel / Hinweis |
|---|---|
| Interface | WAN – die Schnittstelle, über die der Verkehr hinausgeht |
| Version / Protocol | IPv4, any |
| Source / Destination | z. B. 192.168.30.0/24 → any
|
| Translate Source IP | leer = Adresse der Schnittstelle; sonst eine weitere öffentliche IP, eine Virtual IP (z. B. CARP-Adresse) oder ein Alias mit mehreren Adressen |
| Pool Options | Verteilung bei mehreren Übersetzungsadressen (Standard Round Robin, Source Hash für stabile Zuordnung) |
| Static-port | Quellport nicht ändern – für manche VoIP- oder VPN-Geräte nötig |
| Endpoint Independent | „Full-Cone“-Verhalten für UDP (z. B. Spielkonsolen, manche Peer-to-Peer-Anwendungen) |
| Do not NAT | Ausnahme: passender Verkehr wird nicht übersetzt (z. B. Ziel im VPN) |
Typische Fälle: Netze, die über ein IPsec- oder WireGuard-Tunnel ins Internet sollen, VPN-Pools im Full Tunnel, mehrere öffentliche Adressen für unterschiedliche interne Netze, CARP-Adressen im HA-Cluster.
Migration alter Outbound-NAT-Regeln
Wer von älteren Versionen kommt, hat eventuell noch Regeln im alten Outbound-NAT-Format. OPNsense bringt dafür einen Migrationsassistenten mit: Die alten Regeln werden als CSV exportiert, bei Bedarf geprüft und in Source NAT importiert; danach Modus kontrollieren und anwenden. Vorher die Konfiguration sichern (oder bei ZFS einen Snapshot anlegen) – die Konfigurationshistorie erlaubt ebenfalls ein Zurücksetzen.
Destination NAT (Portweiterleitung)
Firewall → NAT → Destination NAT → + – Beispiel: HTTPS von außen auf einen internen Webserver:
| Feld | Wert |
|---|---|
| Interface | WAN |
| Version / Protocol | IPv4 / TCP |
| Source | any (oder ein Alias mit erlaubten Absendern, z. B. Partnernetze, GeoIP-Alias) |
| Destination / Destination Port | WAN address / 443
|
| Redirect Target IP / Port | 192.168.20.10 / 443 (bei Portbereichen nur den ersten Port; any übernimmt den Zielport)
|
| Firewall rule | siehe unten |
| Description | HTTPS Webserver |
Firewall-Regel zur Portweiterleitung
Eine Weiterleitung allein lässt noch keinen Verkehr durch. Das Feld Firewall rule bietet:
- Manual (Standard und laut Hilfetext empfohlen): eine eigene Firewall-Regel unter Firewall → Rules (WAN) anlegen – Ziel ist die interne Adresse und der interne Port (
192.168.20.10:443), da die Regel nach der Übersetzung ausgewertet wird. - Pass: Der Verkehr wird direkt durch die NAT-Regel erlaubt (nicht in der Regelliste sichtbar).
- Register rule: OPNsense erzeugt automatisch eine Schnittstellenregel, die sich durch Regeln mit höherer Priorität übersteuern lässt.
Manuelle Regeln sind übersichtlicher und lassen sich gezielt einschränken (Quellen, Zeiten, GeoIP, Logging).
Weitere Optionen
- No RDR (NOT): Ausnahme – passender Verkehr wird nicht umgeleitet (z. B. vor einer allgemeinen Umleitungsregel).
- Umleitung auf die Firewall selbst: z. B. alle DNS-Anfragen (Port 53) im LAN auf Unbound umleiten – Ziel any außer der Firewall, Redirect Target
127.0.0.1, Port 53. So werden fest eingetragene fremde DNS-Server umgangen. - Pool Options bei mehreren Zieladressen (einfache Lastverteilung).
NAT Reflection (Hairpin NAT)
Greift ein interner Client auf die öffentliche Adresse eines Dienstes zu, der per Portweiterleitung im eigenen Netz liegt, funktioniert das ohne NAT Reflection nicht. Lösungen:
- Split DNS (empfohlen): Der öffentliche Name wird intern direkt auf die interne Adresse aufgelöst – per Host Override in Unbound.
- NAT Reflection: global unter Firewall → Settings → Advanced (Reflection for destination NAT, Reflection for 1:1, Automatic source NAT for Reflection) oder je Regel über das Feld NAT Reflection (Use system default, Enable, Disable).
Split DNS ist schlanker und vermeidet, dass interner Verkehr über die Firewall „umgelenkt“ wird; NAT Reflection eignet sich, wenn Clients nur die öffentliche Adresse kennen.
One-to-One NAT
Firewall → NAT → One-to-One NAT: Eine externe Adresse (oder ein Netz) wird fest auf eine interne Adresse (bzw. ein gleich großes Netz) abgebildet – ein- und ausgehend.
- Type BINAT (Standard): bidirektional, bei gleich großen Netzen die beste Wahl.
- Type NAT: erlaubt auch ungleich große Netze.
- Die externe Adresse muss auf der Firewall vorhanden sein (zusätzliche öffentliche IP als Virtual IP, z. B. IP Alias oder CARP-Adresse).
- Eingehende Firewall-Regeln auf die interne Adresse anlegen.
Einsatz: Server mit eigener öffentlicher Adresse oder Standortkopplungen mit überlappenden Netzen (siehe OPNsense - NAT before IPSEC).
NPTv6
Firewall → NAT → NPTv6 übersetzt ein internes IPv6-Präfix (z. B. ULA fd00:1234::/64) 1:1 auf ein externes Präfix. Ist das externe Präfix dynamisch, bleibt es leer und wird über Associated interface aus der Schnittstelle übernommen. Sinnvoll bei wechselnden Provider-Präfixen oder Multi-WAN mit IPv6; für normale IPv6-Netze ist NAT nicht nötig.
NAT und weitere Funktionen
- Multi-WAN: Im Modus Automatic/Hybrid erzeugt OPNsense für jede WAN-Schnittstelle mit Gateway eigene Source-NAT-Regeln – siehe OPNsense - Gateways und Multi-WAN.
- HA-Cluster: Source NAT immer auf die CARP-Adresse des WAN, nie mit Quelle any (sonst erreicht der Backup das Internet nicht).
- Carrier-Grade NAT beim Provider (CGNAT, z. B. bei vielen Mobilfunk- und Glasfaseranschlüssen): Portweiterleitungen funktionieren dann nicht – eine öffentliche IPv4-Adresse beim Provider buchen oder auf IPv6 bzw. VPN-Dienste ausweichen.
Typische Probleme und Lösungen
| Symptom | Ursache und Lösung |
|---|---|
| Portweiterleitung funktioniert nicht | Firewall-Regel fehlt oder zeigt auf die WAN-Adresse statt auf das interne Ziel; Zielsystem hat ein anderes Standard-Gateway; Provider nutzt CGNAT; Dienst lauscht nicht. |
| Von innen ist die öffentliche Adresse nicht erreichbar | NAT Reflection aus – Split DNS einrichten oder Reflection aktivieren. |
| Eigene Source-NAT-Regel ohne Wirkung | Modus Automatic – auf Hybrid oder Manual umstellen; Regel auf falscher Schnittstelle (ausgehend!). |
| Firewall/Backup erreicht das Internet nicht | Source-NAT-Regel mit Quelle any übersetzt auch Verkehr der Firewall auf eine CARP-Adresse – Quelle auf interne Netze beschränken. |
| VPN-Verkehr wird übersetzt | Do not NAT-Regel für VPN-Ziele vor die allgemeine Regel setzen bzw. Policy-Reihenfolge prüfen. |
| VoIP-Telefone verlieren Registrierung / einseitige Sprache | Static-port für die Telefonanlage aktivieren, SIP-ALG der Gegenstelle prüfen, ggf. Endpoint Independent. |
| Webanwendung nach Umstellung auf Destination NAT von außen nicht erreichbar | Interne Firewall des Servers erlaubt nur das lokale Netz, oder Firewall rule manuell und keine Regel angelegt. |
Zur Kontrolle helfen Firewall → Diagnostics → States (übersetzte Verbindungen), das Live-Log und die Option Log an der NAT-Regel.
Fazit
NAT ist in OPNsense 26.7 übersichtlicher denn je: Source NAT, Destination NAT, One-to-One und NPTv6 nutzen dieselbe moderne Oberfläche mit Kategorien, Audit-Historie und HA-Synchronisation. Für den Alltag genügen meist der Modus Hybrid, wenige Portweiterleitungen mit eigenen, eng gefassten Firewall-Regeln und Split DNS statt NAT Reflection. Öffentlich erreichbare Dienste gehören in eine DMZ oder hinter einen Reverse Proxy.
Unterstützung von m.a.x. it
Sie möchten Dienste sicher veröffentlichen, alte Outbound-NAT-Regeln migrieren oder NAT im HA- und Multi-WAN-Betrieb sauber aufsetzen? m.a.x. it unterstützt Sie als OPNsense-Gold-Partner mit OPNsense-Firewall-Services von m.a.x. it und einer Managed Firewall von m.a.x. it.
Siehe auch
- OPNsense - Aliase
- OPNsense - Firewall-Regeln
- NAT
- Source NAT
- Destination NAT
- Portweiterleitung
- Carrier-Grade NAT
- OPNsense - NAT before IPSEC
- OPNsense - Gateways und Multi-WAN
- OPNsense - Hochverfügbarkeit mit CARP und pfsync
- OPNsense - Caddy Reverse Proxy
Links und Quellen
- OPNsense-Doku – Network Address Translation
- RFC 6296 – IPv6-to-IPv6 Network Prefix Translation
- m.a.x. it – OPNsense-Firewall-Services
Über m.a.x. it Die m.a.x. Informationstechnologie AG ist seit über 30 Jahren IT-Partner mittelständischer und großer Unternehmen in München und bietet maßgeschneiderte Lösungen und Services in den Bereichen Cloud, Cybersecurity, Netzwerk, Windows, Linux und Softwareentwicklung. Sie haben eine Frage zu diesem Artikel oder brauchen Unterstützung?
