Hallo liebes Securepoint-Team!

Spätestens mit der Einführung von IPv6 wird die Verwaltung von Netzwerk-Objekten unübersichtlich. Wir haben teilweise nicht nur IPv4-Adressen und eine IPv6-Adresse, sondern oft mehrere IPv6-Adressen mit verschiedenen Scopes und Gültigkeiten pro Objekt.

Es wäre toll, wenn Netzwerk-Objekte in Zukunft daher mehrere IP-Adressen aufnehmen könnten, und zwar gemischt aus IPv6 und IPv4 - quasi eine Art "Netzwerkgruppe lite". Ich könnte zwar aktuell pro IP-Adresse ein Objekt anlegen, und dann in eine Gruppe gruppieren, das artet aber in sehr vielen Gruppen aus.

Damit so ein Dual-Stack-Mischbetrieb richtig funktioniert im Regelwerk, würden die aktuellen Funktionen für DNAT und Hide-NAT natürlich nicht mehr funktionieren. Es wäre daher sinnvoll, diese in generische Masquerade- und Port-Weiterleitungsfunktionen auszulagern, so wie man das auch von anderen Firewalls kennt, die genau das vermutlich genau aus diesem Grund machen.

Denn in einem Dual-Stack-Betrieb mit verschiedenen Scopes haben wir ja nun folgende Dinge, die per Hide-NAT abgebildet werden müssen, oder vielleicht auch nicht:

• Private IPv4-Adressen (10/8, 172.16/12, 192.168/16) müssen auf die externe IPv4 maskiert werden

• Public-Prefix-IPv6-Adressen (2000::/3) sollten nicht maskiert werden

• ULA-IPv6-Adressen (fc00::/7) müssen/sollten auf eine geroutete IPv6 maskiert werden, falls wir diese ins Internet routen wollen

• SLA-IPv6-Adressen (fec0::/10) sollten vermutlich ähnlich die ULA behandelt werden

• LLA-IPv6-Adressen (fe80::/10) sollen gar nicht erst geroutet werden und eine Maskierung entfällt

All diese verschiedenen Maskierungen pro Protokoll/Scope sind mit NAT als Teil des Regelwerks nur sehr aufwändig zu implementieren.

Ich bin nicht dafür, die Hide-NAT-Funktion im Regelwerk abzuschaffen. Aber ich denke, wir sollten die Option haben, diese nicht nutzen zu müssen und in einem solchen Fall nachgelagerte Maskierungsregeln ein generisch definiertes Hide-NAT durchführen zu lassen.

Quasi: Hide-NAT in der Paketregel ist nur noch die Ausnahme, und sonst greifen die generischen Regeln. Dies würde viele Dinge vereinfachen, vor allem im Dual-Stack-Betrieb. Und vermutlich umgeht das auch einen Quirk der UTMs, der Pakete nicht korrekt maskiert, wenn man Hide-NAT-Regeln mit Accept mischt mit Reject-Regeln ohne Hide-NAT: Dann kommt es nämlich manchmal dazu, dass ein Paket, was akzeptiert und für Hide-NAT markiert sein sollte, eventuell doch nicht maskiert wird.