LANCOM UF-60 DNAT /SAT für internen Host

[lan.kerberos28759]

Guten Tag an alle Leser/innen des LANCOM-Forum,

ich möchte gerne folgendes Szenario abbilden, bin nur leider bisher kläglich gescheitert, nachdem ich verschiedenste Routing-, DNAT, Desktop-Verbindungen, Netzwerk-Objekte-, Schnittstellen-Adressen-Kombinationen ausprobiert habe. Daher hoffe ich hier einen "crack" zu finden, der das Problem kennt oder die Lösung kennt.

Hintergrundinformationen:
LANCOM UF-60 (LCOS FX 11.2 RU1, arbeitet mit den Desktop-Objekten und -Verbindungen)
mehrere Firewalls in verschiedenen Sicherheitszonen im Einsatz
Verbindungen zwischen Firewalls / "Conduits" sind als "exposed" Übergänge und unsichere Bereiche zu betrachten.

Das Zielbild/-verhalten:
Ich möchte, dass der interne Host (z.B. 10.20.1.3/24, befindet sich in Zone 2) über eine "exposed" IP-Adresse (z.B. 172.31.100.3/24) für andere Zonen erreichbar ist. Konkret möchte ich dass der andere Host aus Zone 1 (z.B. 10.10.4.100/24, befindet sich in Zone 1) an sein Gateway 10.10.4.1 wendet. Das Gateway SNATtet auf das Transit-Netz zwischen Firewall-Zone-1 und Firewall-Zone-2 (z.B. 10.10.2.1). Die Firewall-Zone-2 akzeptiert das Paket mit Ziel: 172.31.100.3 auf seinem Transit-Interface 10.10.2.2 DNATtet es aber auf die interne Host-IP-Adresse 10.20.1.3.

Anhand von Packet-Caputres (Wireshark) und Connection Monitoring (LANCOM) kann ich schon mal soweit bestätigen, dass das SNAT und die Allow-Rules und das Routing für Ziele in 172.31.100.0/24 über Gateway 10.10.2.2 auf der Firewall-Zone-1 Seite soweit funktionieren. Es scheint aber, dass die Firewall-Zone-2 die Pakete nicht einmal annimmt bzw. sich für 172.31.100.3 überhaupt nicht zuständig fühlt und noch vor Rule-Check "rejected".

Eigentlich kannte ich diese Szenarien im "Clavister"-Umfeld als SAT ("Static Address Translation"), jedoch war das sehr unkompliziert einzurichten. Stichwort: Port-Forwarding-Rule mit Exposed Host IP-Adresse und SAT auf ein intern definiertes Objekt. Ab diesem Moment hat die Firewall ganz einfach Pakete für die "Exposed Host IP Adresse" akzeptiert, verarbeitet und zugeordnet. Ich hatte angenommen, dass das ein ganz gängiges und technisch bekanntes Szenario im Firewall-Umfeld, auch für LANCOM ist.

Kann mir jemand sagen, wie ich das in der "LCOS FX"-Welt umsetze ? Welche Verbindungen, Regeln und Häkchen fehlen mir hier. Ich habe auch schon nach Funktionen wie "PROXY NAT" gesucht, finde jedoch nichts dazu.

Nachtrag: Was ich glaube ich brauche ist, dass die Firewall auf ihrem Ethernet-/VLAN-Interface mehrere IP-Adressen aus unterschiedlichen Subnetzen akzeptiert. Mit einer einzelnen Netzwerk -> Netzwerk-Verbindung klappt das so nicht, da ich dann den Fehler erhalte: "Die IP-Adressen müssen zum selben Subnetz gehören". Aber dann verstehe ich nicht, wie die Firewall überhaupt auch in einem Internet-Szenario mehrere IP-Adressen "ge-published" kriegt.

Ich danke vorab für die Hilfe....


Viele Grüße

[lna]

wenn die Adresse geroutet an der Firewall vorbei kommt, kann sie in den NAT-Regeln verwendet werden.
auf Verbindungs-Ebene geht nur das maskieren mit der IP der Firewall die am nähesten zum next hop liegt oder ein ein Masquerading als Full-Nat, (ganzes netz auf ganzes netz mappen)
Auf Service-Ebene innerhalb der Verbindung geht auch ein masquerading mit beliebiger IP (ggf. rückroute am nexthop erforderlich).

Ohne Bilder kann ich mir so viele Abstraktionsebenen immer nur schwer vorstellen, ich hoffe ich habe den Sinn getroffen?
da das forum nur 3 uploads je post erlaubt musste ich die screenshots jeweils zu einem Bild gruppieren.

DNAT.jpg

Der Host in Zone 1 schickt das Paket mit Quelle 10.10.4.100 und Ziel 172.31.100.3 los und es soll mit Quelle 10.10.2.1 und Ziel 10.20.1.3 am Host in Zone 2 ankommen.
Dafür macht die Firewall in Zone 1 ein SNAT/MASQ und die Firewall in Zone 2 ein DNAT.

Auf der Firewall Zone 1 brauche ich eine Route die die Exposed Host IP auf die Transfernetz-IP der Zone2 Firewall routet und eine Desktop Regel mit Masquerading:

zone1.jpg

Auf der Firewall Zone 2 brauche ich eine Desktop-Regel mit DNAT

zone2.jpg

[lan.kerberos28759]

Hallo Lukas,

vielen Dank für deine ausführliche Antwort und dass du das visuell sehr schön und verständlich aufgearbeitet hast. Das hat mir sehr geholfen den SNAT und DNAT Zusammenhang nochmal besser zu verstehen. Ich konnte inzwischen bei einem Network Engineer von LANCOM in Erfahrung bringen (an ganz versteckter Stelle im LCOS FX Manual findet man diese Aussage auch), dass SNAT- und DNAT-Adressen nur konfigurierten IP-Adressen der Firewall auf einem Interface (Eth oder VLAN) entsprechen kann und keine "virtuellen" / ausgedachten IP-Adressen verwendet werden können. Die Firewall fühlt sich nur für konfigurierte IP-Adressen verantwortlich. Ich kannte das aus dem Clavister / inControl Umfeld anders, da hier über SAT Rules ("Static Address Translation") auch ausgedachte / "random" IP-Adressen genutzt werden konnte und die Clavister anhand dieser SAT-Rule entschieden hat, dass sie sich für diese IP-Adresse auch zuständig fühlt. Die LANCOM dagegen ignoriert das vollständig.

Also tatsächlich mein Fehler, da die Firewall einen sogar darauf hinweist, wenn ich eine fiktive, unbekannte IP-Adresse bei DNAT-Rules einsetze. Dennoch hatte ich es ignoriert und nun aber die eindeutige Antwort von dem Network Engineer von LANCOM erhalten.

[lna]

Das sehe ich anders, aber das verstehen auch viele nicht.

natürlich klappt das, wenn die Rahmenbedingungen richtig sind und die hast du in deinem Fall im Griff.
Wenn die Firewall das paket geroutet empfängt, nimmt sie es auch dann für dnat, wenn sie die Adresse an keinem interface konfiguriert hat.
Wenn die Firewall ARP für diese Adresse beantworten können soll, dann muss sie die auch am interface anliegen haben.

um in meinem Bild zu bleiben:
Firewall Zone 1 braucht eine Route 172.31.100.3/32 via 10.10.2.2
Firewall Zone 2 braucht keine Rückroute weil ja mit der direkten IP maskiert wird.

[lan.kerberos28759]

Entweder verstehe ich noch etwas falsch oder wir reden aneinander vorbei. Das die Firewall 2 keine Rückroute braucht ist mir so weit klar und auch verständlich. Meine Erkenntnis war jetzt jedoch, dass das Routing über die Firewall 1 (Ziel ist 172.31.100.3/32) klappt, jedoch die Firewall 1 nun auch ein DNAT auf 10.10.2.1 (Transit-IP der Firewall 2) machen müsste, damit die Firewall 2 dieses Paket überhaupt akzeptiert. Ab diesem Zeitpunkt würde es das Ziel 172.31.100.3/32 nicht mehr geben. Was ich aber erreichen wollte ist, dass das Ziel 172.31.100.3 auf der gesamten Strecke bis zur Firewall 2 erhalten bleibt und erst die Firewall 2 wandelt 172.31.100.3/32 in die interne 10.20.1.3/24 um. So... nun ist es aber nach meinem Verständnis nicht möglich, dass die Firewall auf seinem Transit-VLAN-Interface die Adressen 10.10.2.1 und 172.31.100.3 als Ziele akzeptiert, sondern nur konfigurierte Adressen im 10.10.2.0/24 Bereich, es sei denn die Firewall 2 hat eine Route für 172.31.100.3. Dann würde sie natürlich wieder ordnungsgemäß routen wie die Firewall 1. Jedoch soll an diesem Punkt ja garnicht mehr geroutet werden sondern nur noch DNAT auf 10.20.1.3 gemacht werden. Mein Workaround war jetzt für die Firewall 2 im Transit-Netz mehrere IP-Adresse im Bereich 10.10.2.10-.20 anzulegen und diese als Exposed Host IPs zu verwenden und dann auf 10.20.1.3-.13 auf der Firewall 2 zu DNATten.

Zusammengefasst soll heißen, die Firewall 2 akzeptiert ein Paket mit Ziel 172.31.100.3 nur dann, wenn sie auf dem Transit-Netz eine IP-Adresse konfiguriert hat die 172.31.100.3 entspricht oder eine Route in ihrer Routing-Table hat. In meinem aktuellen Szenario und so zeigt es auch dein Bild ab, DNATtet die Firewall 1 hier nichts, sondern sie hat einfach eine Route für Ziel: 172.31.100.3 schicke ich über 10.10.2.1. Die Firewall 2 (10.10.2.1) erhält dann aber ein Paket mit dem Ziel 172.31.100.3 und sagt schlichtweg ich kenne weder die IP-Adresse, noch ist sie meine, noch habe ich einen Routing-Eintrag, trotz dessen das ich diese IP in die DNAT-Rule bzw. Desktop-Verbindung zum internen Client eintrage (dies scheint er einfach zu ignorieren) -> DROP!!!

Deine unteren Bilder (die drei zusammengeführten Bilder) zeigen das, was ich auch probiert habe. Ich trage bei der Desktop-Verbindung von Firewall 2 Transit-VLAN-Interface zu interne Client-IP in die externe Adresse die 172.31.100.3 ein. Das führt jedoch zu dem Fehler, dass die Firewall sagt diese IP-Adresse ist auf meinem Interface nicht konfiguriert und laut LCOS FX Manual und Techniker geht genau das auch nicht. Jetzt wäre aber echt spannend, ob das bei dir wirklich genau so funktioniert?

Sag mir gerne, ob ich hier einen Fehler begehe oder irgendwas architektonisch oder technisch nicht bedenke.


Viele Grüße

[lna]

Das gilt für Full NAT auf der Verbindung - sehe gerade ich war mit meinem Screenshot zu schnell und habs an der falschen stelle eingetragen.

Screenshot 2026-06-24 181254.png

Screenshot 2026-06-24 181235.png

Auf Service-Ebene sollte es gehen, so lässt es mich das auch speichern.
Auf der Verbindungs-Ebene geht es mit Full-NAT nur wenn die Adresse der Firewall gehört. bei einzelports oder portrange "any" klappts auch als geroutete verbindung.

[lan.kerberos28759]

Super ich danke dir. Das werde ich direkt bei uns ausprobieren. Auf Service-Ebene lässt sich also auch eine IP-Adresse eintragen, die die Firewall nicht direkt als seine Eigene am Transit-VLAN verwendet ? Muss ich noch auf etwas bestimmtes bei den "Servicespezifischen Einstellungen" achten ? Unterhalb der Externen IP-Adresse kommt noch das Feld "Externer Port" und weitere Einstellungen. Gibt es hier noch etwas bestimmtes was ich bei meiner Architektur beachten oder konfigurieren muss ? Die Ports sollen ja nicht verändert werden, ein HTTPS / 443 soll auch gerne auf der gesamten Strecke eine 443 bleiben. Klappt das so ?


Viele Grüße

Florian

[lna]

wenn das Port-Feld leer bleibt, dann bleiben die Ports unverändert. Das Feld kann nur sinnvoll genutzt werden wenn ein serviceobjekt mit nur mit einem Port definiert ist, bei einer range bzw. einem any gibt es keine Sinnvolle zuordnung und das Feld muss leer bleiben.
(Mein Any ist 1-65535 tcp+udp + icmp)

[lan.kerberos28759]

Hallo Lukas,

ich hatte nun Gelegenheit das in unserem Testlabor auszuprobieren und leider bleibt die Situation unverändert. Auch die Port-Weiterleitung verhält sich in unserem Szenario wie das DNAT. Die Pakete werden erst von der Firewall akzeptiert, wenn die entsprechende "Externe IP-Adresse" der Port-Weiterleitung auch an dem externen (anfragender Client) Interface der Firewall konfiguriert ist. In meinem Fall bedeutet das, nur IP-Adressen aus dem Bereich 10.10.2.0/24. Kannst du Gegenteiliges berichten?

Ich kann soweit bestätigen, dass das Problem erst bei der Firewall 2 entsteht. Mit Wireshark kann ich sehen, dass das Paket noch korrekt von der Firewall 1 geNATtet und zwischen Firewall 1 und Firewall 2 geht das Paket "verloren".

Im Prinzip habe ich es jetzt entsprechend diesem Video eingerichtet, nur dass in meinem Fall nicht das WAN Objekt ("Globus"-Symbol) verwende, sondern ein Desktop-Netzwerk (Transit-VLAN): https://www.youtube.com/watch?v=Wx58l5a0iZM

Mache ich noch etwas falsch. Gibt es noch bei der Routing-Tabelle 257 etwas zu beachten?

PS: Mir war noch aufgefallen, dass wenn ich eine Verbindung zwischen zwei Host-Objekten ziehe, steht in der Ziel-Adresse einer Port-Weiterleitung oder einer DNAT - Rule die IP-Adressen beider Verbindungsobjekte. Erst wenn das linke Objekt der Verbindung ein Netzwerk-Objekt ist und das rechte Objekt ein Host-Objekt, dann ist die Ziel-IP-Adresse auch nur das Ziel Host-Objekt.