Problem mit 1:1 NAT auf IPv4 in Verbindung mit TCP-Ports

[groove21]

Hallo zusammen,

bei mir läuft die OPNsense virtualisiert in Proxmox:
OPNsense 24.1.8-amd64
FreeBSD 13.2-RELEASE-p11
OpenSSL 3.0.13

Ich betriebe ein 1:1 NAT. Dies funktioniert seit Jahren schon einwandfrei.
Ich habe heute das Update auf die neuste Version angestoßen. Danach gingen meine TCP-Verbindungen auf IPv4 nicht mehr, nur noch UDP war funktionsfähig.
Firewall-Regeln liegen vor, lief ja die ganze Zeit einwandfrei.
Ich habe dann wieder einen Snapshot zurückgespielt und alles war wieder gut.
Mit IPv6 auf dem gleichen Server habe ich weder mit TCP noch mit UDP Probleme.
Ich habe im Changelog gelesen, dass am 1:1 NAT was geändert wurde und vermute hier die Ursache:

This is the last bit of preparation for the upcoming 24.7 series reimplementing one-to-one NAT using MVC/API and a number of plumbing changes.
firewall: migrate one-to-one NAT to MVC/API


Ist jemand schon über das gleiche Problem gestolpert?
Braucht es irgendwo eine andere Einstellung?

Bin über jeden Tipp dankbar.

Gruß

[Patrick M. Hausen]

Hast du die Firewall nach dem Update rebootet?

[groove21]

Jop vor dem Reboot war noch alles in Ordnung. Nach dem Reboot war nur noch UDP erreichbar, TCP nicht mehr.

[groove21]

Habe es heute Morgen nochmal probiert, aber dann den Snapshot wieder zurückgespielt:

Mit der neuen Version laufen die Zugriffe wie beispielsweise 443 TCP in die Default Block Rule. Mit der alten Version nicht (siehe Anhang).
Die Firewall-Regeln sitzen auf dem WAN-Interface (über Firewall-Gruppe mit Mitglied WAN) auf der IP 10.201.1.1 (über eine Alias vom Typ Host als Destination).
Durch das 1:1 NAT hat das immer gepasst.

Braucht es noch etwas an neuen Regeln? Und wenn ja, warum?

[osmom]

Im Englischen Forum steht dazu,  das mit dem Update eine Regel gelöscht wird: https://forum.opnsense.org/index.php?topic=41122.0
Diese musst du wohl neu erstellen.

[groove21]

Hallo osmom,

danke für den Thread. Ich stehe aber gerade auf dem Schlauch:

Was brauche ich für eine Outbound NAT-Regal? Da werde ich aus dem Thread im Englischen Forum leider auch nicht schlau.

Aktuell sieht es so aus wie im Screenshot.

Hast du eine Idee?
Und wieso braucht es eine ausgehende Outbound NAT? Im Log wird dich der incoming Traffic über die Default-Rule blockiert oder verstehe ich was falsch?

Gruß

[groove21]

P.S.: Nach dem Update sehen die automatic Rules im Outbound-NAT genauso aus wie vorher. Ich verstehe gerade nicht, was da weggeflogen ist. Ich habe das gleiche Verhalten wie im Englischen Thread, dass es auf der Firewall an kommt, anstatt auf der Ziel-VM.

Folgende Einstellungen habe ich entdeckt, aber die waren auch schon immer so (siehe Screen).

Auch finde ich es komisch, das wohl nur TCP betroffen ist, UDP aber in Ordnung zu sein scheint. Zumal ich Port 54 TCP/UDP in einer Regel auf WAN habe (natürlich von der Source-IP eingeschränkt).

[osmom]

Hallo Groove,

ich selbst habe keine Erfharung mit One-to-One NAT und würde daher den Server über Port Forward-NAT ins Internet stellen.
Notfalls mit einer NAT auf Destination- und Redirekt- Port "any"

[groove21]

Hier gehts im englischen Thread weiter, Franco ist schon dran: https://forum.opnsense.org/index.php?topic=41122.0

[wirehire]

bei mir war es der outbound, weil es über eine andere ip auf wan 1:1 umgesetzt wird. diese war nach dem update weg, sodass es nur noch über die normale wan ip raus ging.

[wirehire]

schau mal bitte bei der 1:1 übersicht , bevor du die regel editierst ob dein external network angezeigt wird oder nur in der 1:1 regel?

[groove21]

Hallo wirehire,

ist bei mir das gleiche. Die externe IP wird in der Übersicht nicht mehr angezeigt, sondern nur in der Bearbeitungsübersicht, ist wohl ein Anzeige-Bug.
Des Weiteren wird die Destination (in meine Fall war es "any") gleichgesetzt mit der IP aus Source (dort hatte ich zuvor auch eine 10er-IP mit /32). Somit wird während des Updates Daten geändert, was man erst mal finden muss.
Ich habe die Erkenntnis nun auch im englischen Thread gepostet.

Lange Rede, kurzer Sinn: Ich weiß nicht ob hier wirklich eine Rule das Problem war oder die falsch überschriebenen Einstellungen während des Updates (bekomme ich jetzt aber auch nicht mehr nachgestellt).
Fakt ist: Das Hotfix auf 24.1.9_1 funktioniert selbst dann nicht ohne manuellen Eingriff, wenn man von 24.1.8 kommt (hatte ja den Snap zurückgespielt).

Gruß

[franco]

https://github.com/opnsense/core/commit/5b73396f08

# opnsense-patch 5b73396f08


Grüsse
Franco

[franco]

Und der hier... meh ;(

https://github.com/opnsense/core/commit/6cbd3ca15

[groove21]

Nach intensiven Tests mit Franco kann ich bestätigen, dass mit dem Hotfix 24.1.9_3 nun alles funktioniert wie es soll.