Ich habe eine OPNsense mit folgendem Setup:
LAN-Netzwerk: 192.168.71.0/24
WAN-Seite: Zyxel DSL-Modem, PPPoE-Einwahl durch OPNsense
DSL-Modem: IP-Adresse 192.168.100.1
Ich möchte aus meinem LAN auf die WebUI des DSL-Modems zugreifen, welches die IP-Adresse 192.168.100.1 hat. Dazu habe ich ein weiteres Interface auf der OPNsense auf dem selben physischen Ethernet-Port angelegt und der OPNsense darauf die IP-Adresse 192.168.100.2 gegeben.
Bisherige Schritte:
Ein Interface namens DSL-Modemconf mit der IP-Adresse 192.168.100.2/24 wurde angelegt.
Firewall-Regeln:
Auf dem LAN-Interface ist eine any-to-any Regel konfiguriert.
Eine Outbound-NAT-Regel wurde konfiguriert, die den Verkehr von 192.168.71.0/24 zur IP-Adresse 192.168.100.1 auf die IP-Adresse 192.168.100.2 umsetzt.
Die Routing-Tabelle zeigt die Route 192.168.100.0/24 auf das Interface DSL-Modemconf.
Ping-Tests:
Ping von der OPNsense mit der Source-IP 192.168.100.2 funktioniert.
Ping von der OPNsense mit der Source-IP 192.168.71.1 funktioniert nicht.
Firewall-Logs:
Keine geblockten Pakete in den Firewall-Logs.
ARP-Tabelle:
Der ARP-Eintrag für 192.168.100.1 zeigt die korrekte MAC-Adresse des Modems an.
NAT Reflection:
Reflection for port forwards, Reflection for 1:1, Automatic outbound NAT for Reflection wurden aktiviert.
Frage:
Warum kann ich aus meinem LAN die WebUI des DSL-Modems nicht erreichen, obwohl die NAT-Regel und Firewall-Regeln korrekt konfiguriert sind und keine Pakete geblockt werden?
Ich bin gerade von pfSense auf OPNsense umgestiegen und hatte genau dieses Setup vorher mit der pfSense so am laufen, und bin jetzt mit meinem Latein am Ende.
Hast du die Box schon neu gestartet?
Nach meiner Erfahrung braucht es das, damit die Outbound NAT Regel greift. Eventuell hilft auch das Löschen der States.
(Diese Erfahrung stammt auch von pfSense)
Das Thema konnte schon gelöst werden in einem gleichnamigen, englischen Thread Outbound NAT to access WebUI of DSL Modem (https://forum.opnsense.org/index.php?topic=46483).
Ein Neustart war bisher noch nie notwendig für mich bei NAT Regeln - oder irgendwelchen Firewall Regeln, das wäre ja noch der Hammer.
Ganz typische Situation:
Du versuchst, das Modem ohne der NAT Regel zu erreichen. OPNsense setzt einen State für das bestehende NAT mit der WAN IP (interne IP (WAN IP) > Modem IP), weil die Verbindung ja erlaubt ist, auch wenn sie ins Nichts führt. Solange dieser besteht, nutzt OPNsense ihn weiterhin für die Verbindung intern IP > Modem IP, also mit Masquerading auf die WAN IP, ungeachtet einer neuen NAT Regel.
Paket zum Ziel WAN IP schickt das Modem aber nicht zur OPNsense zurück, weil es dafür keine Route hat.
Für mich ist das ein ganz normales Verhalten, für andere mag es "ein Hammer" sein.