# OPNsense 1:1 NAT: Exklusive öffentliche IPs für interne Hosts

TL;DR / Management Summary Während Port-Forwarding (Artikel 559) nur einzelne Ports teilt, ordnet 1:1 NAT (One-to-One NAT) eine komplette öffentliche IP-Adresse exklusiv einem internen Host zu. Alle Ports (TCP/UDP/ICMP) werden bidirektional gemappt. Für Senior Admins ist dies die bevorzugte Methode für DMZ-Server, die viele Dienste gleichzeitig anbieten (z.B. Mailserver, Web-Cluster), da sie das Regelwerk vereinfacht und asymmetrisches Routing verhindert.

# 1. Einführung & Konzepte

Eins-zu-Eins Mapping.

In einer 1:1 NAT Konfiguration agiert die OPNsense als transparenter Proxy für eine ganze IP.

# Warum 1:1 NAT?

# 2. Einrichtung in der Praxis

Mapping und Virtuelle IPs.

# Schritt 1: Virtual IP (VIP) anlegen

Damit OPNsense auf ARP-Anfragen für die zusätzliche öffentliche IP antwortet:

  1. Interfaces -> Virtual IPs -> Settings.
  2. Typ: IP Alias (oder Proxy ARP).
  3. Address: Die zusätzliche öffentliche IP (z.B. 80.1.1.10/32).
  4. Interface: WAN.

# Schritt 2: 1:1 NAT Regel erstellen

Firewall -> NAT -> One-to-One.

  1. Interface: WAN.
  2. External subnet: 80.1.1.10 (Die VIP).
  3. Internal IP: 10.0.50.10 (Der Server im LAN).
  4. Destination: Any (Mapping gilt für alle Ziele).

# Schritt 3: Firewall-Regeln am WAN

Nun müssen Sie die Ports explizit erlauben: Firewall -> Rules -> WAN.

# 3. Deep Dive: Reflection & Binat

Interner Zugriff.

# NAT Reflection bei 1:1 NAT

Genau wie beim Port-Forwarding (Artikel 559) brauchen interne User Hilfe, um den DMZ-Server über seine öffentliche IP zu erreichen.

# Bi-Directional NAT (BINAT)

In OPNsense ist 1:1 NAT standardmäßig bidirektional. Das bedeutet, der Server nutzt für ausgehende Verbindungen immer seine zugeordnete öffentliche IP. Dies ist perfekt für SMTP-Versand.

# 4. Day-2 Operations: DMZ-Isolation

Die Grenze härten.

Ein Server mit 1:1 NAT steht “nackt” im Internet, wenn die Firewall-Regeln zu offen sind.

# 5. Troubleshooting & “War Stories”

Wenn das Mapping versagt.

# Top 3 Fehlerbilder

  1. Symptom: Server ist von außen nicht erreichbar.

    • Ursache: Virtual IP (VIP) wurde nicht angelegt. Der ISP schickt das Paket, aber OPNsense fühlt sich nicht zuständig (antwortet nicht auf ARP).
    • Lösung: VIP Typ IP Alias prüfen.

  2. Symptom: Ausgehender Traffic nutzt die falsche IP.

    • Ursache: Eine manuelle Outbound-NAT Regel (Artikel 559) hat eine höhere Priorität als die 1:1 NAT Regel.
    • Lösung: 1:1 NAT Regeln werden vor Outbound-NAT verarbeitet, prüfen Sie jedoch auf “Hybrid” Modus Überlappungen.

  3. Symptom: Ping auf die öffentliche IP geht, aber Dienste nicht.

    • Lösung: Regeln am WAN-Interface prüfen. 1:1 NAT erlaubt nur den Traffic-Fluss, nicht den Zugriff!

# “War Story”: Der schweigende Mailserver

Ein Kunde bekam keine Mails mehr. Der MX-Record zeigte auf die korrekte IP, und der Server lief. Die Entdeckung: Ein Admin hatte ein 1:1 NAT für einen neuen Web-Server eingerichtet und dabei versehentlich ein /24 Subnetz statt einer /32 IP gemappt. Das Ergebnis: Die OPNsense versuchte, ein ganzes IP-Band auf eine einzige interne IP zu biegen. Alle anderen 1:1 Mappings (inklusive des Mailservers) wurden dadurch überschrieben. Lehre: Nutzen Sie bei 1:1 NAT immer /32 (Single Host) Masken, außer Sie mappen wirklich zwei identische Netze 1-zu-1 aufeinander.

# 6. Monitoring & Reporting

Log-Analyse.

# NAT Session Tracking

In der Firewall -> Diagnostics -> States Liste können Sie nach der externen IP filtern. Sie sehen dort alle aktiven Sessions, die gerade über das 1:1 Mapping laufen.

# 7. Fazit & Empfehlung

1:1 NAT ist die sauberste Lösung für Server mit mehreren Diensten.

# Anhang: Cheatsheet

Aufgabe Pfad
Virtual IPs verwalten Interfaces -> Virtual IPs -> Settings
1:1 NAT anlegen Firewall -> NAT -> One-to-One
Status prüfen Diagnostics -> Network -> States
ARP Check Diagnostics -> Network -> ARP Table

# Referenzen