Nach Upgrade auf 24.1 funktionieren einzelne NAT Forwardings nicht mehr

[udo1toni]

Ich habe seit Jahren ein paar NAT Forwardings eingerichtet, die bisher auch immer funktionierten. Nach dem Upgrade nun aber nicht mehr.
Was habe ich schon versucht? NAT Forwardings gelöscht und neu angelegt, Ports geändert, Reihenfolge der Rule geändert, komplette Konfiguration neu eingelesen...
Der Witz: Mein Telefon benötigt ebenfalls NAT Forwarding, die Rules stehen direkt unter den nicht funktionierenden, telefonieren geht aber...
Im Live Log sehe ich, dass die Default deny / state violation rule auslöst, obwohl die ja eigentlich als letztes ansprechen soll.
Ich nutze nur ein WAN Interface (allerdings IPv4+IPv6) und habe an anderer Stelle (englischer Forenteil) gelesen, dass teilweise das Gateway weggeflogen wäre. In den Interfaces steht als Option auch nur Auto-detect zur Verfügung, ich kann gar kein bestimmtes Gateway auswählen...

Irgendwelche Ideen, was ich falsch mache?

[blodone]

Bei mir funktionieren UDP NAT auf WAN nicht direkt beim reboot wenn die WAN Adresse nicht bekannt ist und nachträglich gesetzt wird.

https://forum.opnsense.org/index.php?topic=38525

Ist dir das direkt nach dem Reboot aufgefallen?

[udo1toni]

Das Problem besteht dauerhaft. OPNsense verhält sich einfach so, als seien die Rules überhaupt nicht vorhanden, egal was ich auch anstelle.

[Patrick M. Hausen]

Zeig doch mal bitte eine der betroffenen Regeln mit allen Details. Sonst ist das Kaffeesatzleserei ...

[udo1toni]

Gerne.
By the way: Gibt es einen effizienteren Weg, als mühsam alles abzuschreiben oder einen Screenshot zu machen?

Interface: WAN (pppoe Interface, Telekom, IPv4+v6)
TCP/IP Version : IPv6 (hab die Rules zuletzt aufgetrennt, vorher mit v4+v6)
Protocol: TCP
Destination: WAN address
Destination Port Range: from 1122 to 1122
Redirect target IP: Alias auf ssh
Redirect target port: SSH
Pool Options: Default
NAT Reflection: Use system default
Filter rule association: (automatisch generiert)

Update: da ich noch eine zweite Kiste habe, die noch nicht upgedatet ist, habe ich mal kurz auf die alte Version zurückgeschwenkt.
Nun muss ich meine ursprüngliche Behauptung revidieren, dass das Problem mit der Version 24.1 zusammenhängt. Das Problem muss schon vorher aufgetreten sein, was es nun etwas schwieriger macht, es einzugrenzen...

Was mir allerdings bei intensivem Nachdenken dazu einfällt: evtl. ist das eigentliche Problem hier IPv6, denn gewöhnlich verwende ich den Remote Zugriff von meinem Smartphone aus von der Arbeit, dort bin ich natürlich in einem (IPv4 only) WLAN eingeloggt, so dass alle Anfragen immer über IPv4 rein kommen. Das kann ich aber momentan nicht verifizieren, da ich Urlaub habe. Wenn ich mein Smartphone aus dem WLAN raus nehme geht es natürlich nur über IPv6, andere Clients aus dem LAN heraus haben eine lange Wartezeit, bauen anschließend aber eine Verbindung auf (evtl. über IPv4?)

[Patrick M. Hausen]

Bei Filter rule association aktiviere mal "Pass".

[blodone]

Ah das ist Inbound NAT, das ist was anderes. Aber hier kannst du auch gut mit tcpdump -i interface port PORT debuggen ob da was durchkommt oder nicht.

Bei Inbound NAT hab ich keine Probleme, nur outbound NAT

[udo1toni]

Nein, das hat leider keine Auswirkung. Auch mit pass statt automatischer Rule wird (für IPv6) die default deny rule angewandt.

[udo1toni]

Kann es mit den verschiedenen IPv6 Adressen zu tun haben?
WAN hat ja automatisch zwei unterschiedliche IPv6, die eine mit fe80:..., die andere mit 2003:... Im AAAA Record steht die 2003:... drin

Allerdings, selbst wenn ich als Destination any eintrage, wird die Rule nicht berücksichtigt.

[Patrick M. Hausen]

Testest du denn wirklich von außen? Und wozu brauchst du eingehendes Portforwarding für IPv6? Da lässt man das NAT eigentlich weg und erlaubt einfach die Ports direkt auf die IPv6-Zieladresse.

[udo1toni]

Ja, definitiv. ich schalte am Smartphone WLAN aus...

wozu brauchst du eingehendes Portforwarding für IPv6? Da lässt man das NAT eigentlich weg und erlaubt einfach die Ports direkt auf die IPv6-Zieladresse.

Stimmt auffallend. Aber wie konfiguriere ich das denn? Weil... die v6-IP ist ja erst mal gar nicht öffentlich bekannt. Das Prefix wird ja auch dynamisch vergeben, und der hintere Teil der IP des Endgeräts wird doch auch regelmäßig (über die Private Extensions? heißt das so?) geändert.
Ich scheine da noch etwas Nachholbedarf zu haben...

[Patrick M. Hausen]

Für Server ist der Host-Teil via SLAAC statisch. Privacy Extensions sind eine Sache für Desktop- und Mobil-Systeme. Das dynamische Prefix sollte irgendwie per DynDNS erschlagbar sein. Da fehlt mir aber die Erfahrung, weil ich grundsätzlich überall feste Adressen habe, wo ich eingehende Dienste brauche.

Das heißt ja, die externe Adresse deiner Firewall ändert sich auch dauernd. Dann nützt die das Port-Forwarding ja erst mal auch nix?

Ich bin mir nicht sicher, ob das für IPv6 so überhaupt funktionieren soll. Wenn du unbedingt ein TCP-Forwarding auf der Ebene brauchst, kannst du natürlich immer HA-Proxy benutzen. Der wird funktionieren.

[udo1toni]

Na, mit IPv4 ist das kein Ding, ddclient schreibt die IP automatisch um, das funktioniert sehr zuverlässig. ddclient setzt auch die AAAA Records passend, aber eben eine volle Adresse (halt die vom WAN-Interface, keine Ahnung ob man das beeinflussen kann)