Hairpin-NAT an 1783

[noses]

Hallo zusammen,

ich benötige für einen speziellen Anfwendungsfall ein Hairpin-NAT, also quasi eine zusätzliche Source-NAT-Regel.

Hintergrund:
Eine externe URL verweist auf die WAN-IP des Lancom. Ankommender Traffic wird mit NAT-Regeln auf einen internen Server geleitet. Soweit so gut und täglich Brot.

Nun fragen Clients aus dem internen Netz ebenfalls die besagte URL an. Im einfachsten Fall könnte man nun ja Split-DNS nutzen und die URL im internen Netz anders auflösen als extern und NAT wäre im Prinzip nicht erforderlich.

Aus technischen Gründen jedoch (der Server, ein SIP Session-Boarder-Controller verlangt dies so) funktioniert Split-DNS nicht und ich muss mit Source-NAT arbeiten.

Die konkrete Frage iss also, wie konfiguriere ich Hairpin-NAT an einem Lancom-Router. Im Einsatz ist ein 1783VA mit Firmware 10.12. oder gar schon 10.20. Da müsste ich im Zweifel noch einmal nachsehen.


Vielenk Dank für eure Hilfe!

[backslash]

Hi noses,

für dein Szenario mußt du nichts besonderes machen... Sprich die URL aus dem LAN einfach "normal" an. Dann geht das Paket zum LANCOM, das LANCOM sieht, daß es an die eigene WAN-Adresse gerichtet ist, "loopbackt" es zurück und macht dann das Portforwarding...

Gruß
Backslash

[Dr.Einstein]

Hi zusammen,

also ich habe die Erfahrung gemacht, dass das je nach verwendeter WAN Technik funktioniert oder nicht. Habe jetzt bloß nicht im Kopf, ob IPoE/DHCPoE ging, oder nicht ... Zumindest hatte ich die Probleme bis LCOS 9.24 gesehen, danach nicht mehr begegnet weil versucht im Vorfeld durch lokal/global unterschiedliche DNS Auflösungen. Bei Bintec kann man hierfür extra NAT Loopback für die jeweilige WAN Verbindung aktivieren.

Gruß Dr.Einstein

[backslash]

Hi Dr.Einstein,

lso ich habe die Erfahrung gemacht, dass das je nach verwendeter WAN Technik funktioniert oder nicht. Habe jetzt bloß nicht im Kopf, ob IPoE/DHCPoE ging, oder nicht ... Zumindest hatte ich die Probleme bis LCOS 9.24 gesehen, (...)

Das Problem ist, daß diese Funktion gerne mal kaputtgeht, denn niemand hat sie direkt auf dem Schirm. Dann braucht es seine Zeit, bis irgendwer meldet, daß es nicht mehr funktioniert... Z.Zt. (also mit der 10.20) soll es aber funktionieren...

Gruß
Backslash

[Koppelfeld]

für dein Szenario mußt du nichts besonderes machen... Sprich die URL aus dem LAN einfach "normal" an. Dann geht das Paket zum LANCOM, das LANCOM sieht, daß es an die eigene WAN-Adresse gerichtet ist, "loopbackt" es zurück und macht dann das Portforwarding...

ACH, S'WÄR SO SCHÖN WENN'S SO WÄRE ...
("Neue Deutsche Welle", J. Witt, "Kosmetik")

Problem #1:
Du gehst mit der externen IP 'raus, bloß kommst Du beim (internen) Zielrechner mit einer (ebenfalls internen) IP an.
Also schickt der Zielrechner die Antwort an sein lokalen Interface, der Router wird nicht mehr angesprungen.
Da ist eine ganz üble iproute2 / iptables - Frickelei notwendig. Ob und wie man das unter Windows machen kann,
ist mir ein Rätsel.

Problem #2: #AUFSCHREI
Machmal, wenn eine "überlappende" DMZ konfiguriert ist, muß man explizit die zu erreichende IP in die Routingtabelle eintragen mit dem Ziel "Provider-Gateway". Sonst klappt es nicht. Hat mich 1 1/2 Tage gekostet.

[backslash]

Hi Koppelfeld,

Du gehst mit der externen IP 'raus, bloß kommst Du beim (internen) Zielrechner mit einer (ebenfalls internen) IP an.
Also schickt der Zielrechner die Antwort an sein lokalen Interface, der Router wird nicht mehr angesprungen.

nein... Das abgehende Paket wird maskiert, d.h. auf dem Server wirst du als Quelle der eingehenden Session die öffentliche IP des LANCOMs sehen... Und an die schickt der Server dann auch die Antwort. Es findet also quasi ein doppeltes NAT statt LAN -> ausgehend NAT auf öffentliche IP -> einkommend NAT für Portforwarding -> LAN

Machmal, wenn eine "überlappende" DMZ konfiguriert ist, muß man explizit die zu erreichende IP in die Routingtabelle eintragen mit dem Ziel "Provider-Gateway". Sonst klappt es nicht. Hat mich 1 1/2 Tage gekostet.

wenn du mit "überlappender" DMZ eine DMZ mit öffentlichen Adressen meinst, dann hast du recht, denn der Router will Pakete für die öffentlichen Adreessen natürlich direkt zustellen. Wenn du da das doppelte NAT erzwingen willst, dann mußt du den von dir beschriebenen Weg wohl oder übel gehen

Aber: Wenn man schon öffentliche Adressen hat und in der DMZ verwendet, dann sollte man auf den ganzen NAT-Kram verzichten und die Server direkt unter ihren öffentlichen Adressen ansprechen. Das hat vor allem den Vorteil, daß du auf dem Server bei einer Anfrage aus deinem Netz auch sehen kannst, von wem sie kam....

Gruß
Backslash

[Koppelfeld]

Moin !

Aber: Wenn man schon öffentliche Adressen hat und in der DMZ verwendet, dann sollte man auf den ganzen NAT-Kram verzichten und die Server direkt unter ihren öffentlichen Adressen ansprechen. Das hat vor allem den Vorteil, daß du auf dem Server bei einer Anfrage aus deinem Netz auch sehen kannst, von wem sie kam...

Die Botschaft hör' ich schon. Kann ich aber, jetzt gerade in einer Situation beim Kunden, nicht umsetzen:

Er hat ein festes V4-Netz 1.2.3.56/28, mit Provider-GW 1.2.3.57 und Router-IP 1.2.3.58 / 255.255.255.240
"Echte" DMZ, ebenfalls mit 1.2.3.58 / 255.255.255.240
Alle Einträge in der Routing-Tabelle sind mit "Nur Intranet maskieren" ausgeführt. Muß zumindest für die Default-Route zwangsläufig so sein,
sonst kommst Du logischerweise nicht von der DMZ aus mit der gewünschten IP nach draußen.

So weit, so gut. Alle sind glücklich, bloß der Chef (schlimmer noch, dessen Gattin) ist sauer. Denn:

Es gibt einen Mailserver, naheliegenderweise in der DMZ, mit
1.2.3.59 / 255.255.255.240 -- ABER AUCH MIT
192.168.140.6 / 255.255.255.0 .

Das ist dem Umstand geschuldet, daß etwa 180 Windows-Clients an dem Server hängen - und die Ausspuck-2016 - Mailclients machen einen höllischen Traffic. Den will ich gar nicht über den Router prügeln. Abgesehen sind "DNS-Server" und "Default Gateway" nicht unbedingt Angaben, mit denen "Windows" sinnvoll umgehen könnte. Deswegen sind die Arbeitsplatzrechner nur lokal angebunden und beziehen alle externen Informationen über Proxies.
Die Iphones des mobilen Mitarbeiter erreichen den Mailserver problemlos über das externe Interface.

Der Chef und seine Gattin brauchen für einige Applikationen LAN-Zugriff und sind "außerhalb" im Internet und "innerhalb" der Firma via WLAN im 192.168.140.0. Und jetzt kracht es: Jeder Lagerarbeiter kann seine Mails abrufen, bloß nicht Chef und Chefin.

Am liebsten würde ich eine kleine DNS-Spielerei veranstalten, aber momentan besteht diese Möglichkeit nicht.


Wie kann ich die Situation lösen ?

[backslash]

Hi Koppelfeld,

Am liebsten würde ich eine kleine DNS-Spielerei veranstalten, aber momentan besteht diese Möglichkeit nicht.

aber genau das wäre die Lösung... Im internen Netz löst du den Mailserver auf die 192.168.140.6 auf und alle - Lagerarbeiter und Chef mit Gattin - nutzen einfach das "lokale" Ende des Mailservers...

Gruß
Backslash

[Dr.Einstein]

Blöd nur, wenn externer Port != interner Port. Dann hilft DNS auch nicht wirklich weiter.

[backslash]

Hi Dr.Einstein

Blöd nur, wenn externer Port != interner Port. Dann hilft DNS auch nicht wirklich weiter.

wenn man Ports mappen will, dann betreibt man auch keine DMZ mit öffentlichen Adressen, sondern macht NAT und Portforwarding... und das funktioniert ja auch, wie beireits ganz zu Anfang dieses Threads beschrieben

Gruß
Backslash

[noses]

Hi noses,

für dein Szenario mußt du nichts besonderes machen... Sprich die URL aus dem LAN einfach "normal" an. Dann geht das Paket zum LANCOM, das LANCOM sieht, daß es an die eigene WAN-Adresse gerichtet ist, "loopbackt" es zurück und macht dann das Portforwarding...

Gruß
Backslash

Hallo Backslash,

vielen Dank für Deine Antwort und sorry für die späte Reaktion. Anscheinend hat hat das Board mir keine Benachrichtigung über neue Beiträge geschickt (ist eingeschaltet in meinen Benutzereinstellungen) somit habe ich dass erst heute gelesen.

Nun zur eigentlich Antwort, die mich ziemlich überrascht und gleichzeitig an Lancom zweifeln lässt.

Sollte es so funktionieren wie von Dir beschrieben - ein Test steht noch aus - dann muss sich der Lancom-Support schämen. Von dort bekam ich diverse Antworten mit dem letzlichen Ergebnis, dass die Lancom-Router das nicht können. Auch im Handbuch ist dazu nirgends etwas zu finden, also muss ich denen das zunächst glauben.


Weiterhin beunruhigt mich, dass es von der Firmware abhängig zu sein scheint. In 10.20 funktioniert es also, ob es dann in 10.21 immer noch funktioniert, steht dann in den Sternen, weil das niemand auf dem Schirm hat ?! Auf solche Dinge habe ich wenig Lust, das macht nur Ärger, weil ich nicht sicher stellen kann, dass es dauerhaft und von der Firmware unabhängig funktioniert.

Manch Billigrouter für 1/10 des Preises im Vergleich zu Lancom kann das besser. Bitte nicht falsch verstehen. Ich mag Lancom und habe mich ja bewusst für eine Partnerschaft entschieden, aber die Antwort von Lancom hat mich doch ziemlich entsetzt, ist sie doch das glatte Gegenteil von dem, was Du geschrieben hast. Und die sollten es eigentlich (besser) wissen.

Dir in jedem Fall vielen Dank.

Gruß
Michael

[cpuprofi]

Hallo Michael,

...aber die Antwort von Lancom hat mich doch ziemlich entsetzt, ist sie doch das glatte Gegenteil von dem, was Du geschrieben hast. Und die sollten es eigentlich (besser) wissen...

"besser" als Backslash? Na das glaube ich nicht... zumal er einer der Entwickler bei Lancom ist...

Grüße
Cpuprofi

[noses]

Hallo Michael,

...aber die Antwort von Lancom hat mich doch ziemlich entsetzt, ist sie doch das glatte Gegenteil von dem, was Du geschrieben hast. Und die sollten es eigentlich (besser) wissen...

"besser" als Backslash? Na das glaube ich nicht... zumal er einer der Entwickler bei Lancom ist...

Grüße
Cpuprofi

Das konnte ich ja nicht wissen ändert aber nix an der schwachen Leistung vom Support.