Port-Forwarding-Tabelle externe IP-Adresse möglich - Bug or Feature?

[Hagen2000]

In der Port-Forwarding-Tabelle kann unter Intranet Adresse (Intranet-Address) - entgegen der Bezeichnung des Eintrags - eine beliebige Adresse eingetragen werden. Konkret wird auch eine externe (öffentliche) IP-Adresse akzeptiert und die Weiterleitung - zurück ins WAN - funktioniert sogar.
Ist das eigentlich so beabsichtigt?

[Dr.Einstein]

Ich finde das Feature top. Dadurch kannst du auch Portweiterleitungen über deine VPN Tunnel verteilen/konfigurieren. Wäre schade, wenn die Möglichkeit entfallen würde.

[backslash]

Hi Hagen,

die Bezeichnung "Intranet Adresse" soll diese Adresse von der "WAN Adresse" absetzen...
es bezieht sich auf die Sichtweise des NAT, nicht darauf, wo sich die Adressen wirklich befinden...

Gruß
Backslash

[Hagen2000]

Dann habe ich ja ein mögliches DNAT gefunden (siehe auch fragen-zum-thema-vpn-f14/vpn-security-a ... ml#p116448).

[plumpsack]

In der Port-Forwarding-Tabelle kann unter Intranet Adresse (Intranet-Address) - entgegen der Bezeichnung des Eintrags - eine beliebige Adresse eingetragen werden. Konkret wird auch eine externe (öffentliche) IP-Adresse akzeptiert und die Weiterleitung - zurück ins WAN - funktioniert sogar.
Ist das eigentlich so beabsichtigt?

Kann ich dann, die anfragenden IP-Adressen aus Russland, China und Co. direkt an das BSI weiterleiten oder taucht dann meine IP-Adersse auf?

Das Innenministerium steht doch auf Datensammelei ... warum nicht auf die von aussen?

[Hagen2000]

Ich glaube, die bekommen schon genug „persönliche“ Anfragen.
Aber im Ernst: Natürlich taucht dann die WAN-IP deines Routers als Absender auf, das wird sauber geNATtet.

[tbc233]

Dass das so funktioniert wie beschrieben ist fast ein Alleinstellungsmerkmal von Lancom und kann manchmal echt praktisch sein.
Ich hab damit auch schonmal bei einem Standortwechsel gewisse Dienste an eine andere öffentliche IP weitergeleitet, vorübergehend bis das DNS Update durch war.
Finde ich klasse.

[Hagen2000]

Wenn ich das richtig verstanden habe, ist die Weiterleitung an eine andere öffentliche IP insofern heikel, weil das von jedermann benutzt werden kann. Es gibt keine Filterung der eingehenden IP-Adressen und auch die interne Firewall wird nicht durchlaufen.

[backslash]

Hi Hagen2000,

Es gibt keine Filterung der eingehenden IP-Adressen und auch die interne Firewall wird nicht durchlaufen.

wie kommst du denn darauf? natürlich laufen auch an öffentliche IPs weitergeleitete Ports die Firewall und können sie dort auch mit Regeln gefiltert werden.
Nur DNS-Namen kannst du in diesen Filtern nicht nutzen, da DNS-Namen zum Einen nur in der Zielspalte möglich sind (und hier sind sie überflüssig, weil du sie Ziel-Adresse durch das Portforwarding eh kennst) und zum Anderen müßte jemand das LANCOM um die Auflösung der Adresse bitten. Das müßte die Quelle sein - die darf aber keine DNS-Anfragen an das LANCOM stellen, weil sie sich "außerhalb" des NAT befindet...

Gruß
Backslash

[Hagen2000]

Dann bin ich ja beruhigt, dass ich das nicht richtig verstanden habe
Nach Betrachten der Skizze im Referenzhandbuch (Kap. 8.3.1 So prüft die Firewall im Gerät die Datenpakete) und den Hinweisen dazu war ich mir nicht sicher.

Und das mit der Quelle in den Filtern wäre in der Tat ein Problem, denn die erlaubten Quellen hätten dynamische IP-Adressen.

[cybersmart]

Ginge es so auch, von einem WAN, das nach innen geNATtet wird den Traffic der an öffentliche IP-Adressen geht komplett in ein anderes WAN weiterzuleiten? Denke nicht, das Port-Forwarding ja eine spezifische Ziel-IP+Port braucht, aber ich würde gerne von WAN "A" kommenden Traffic der an public IPs gehen soll direkt an WAN-B outgoing schicken. Nur haut das dann mit der Rückroute für die Pakete nicht hin ohne eben ein dediziertes Port-Forwarding zu machen.

Anwendungsfall:
Ich habe ein IoT-Netz in dem ein als WLAN/IP Gateway ein Gerät steht, das kein Routing in andere Subnetze unterstützt. Als Workaround habe ich also das IoT Netz im Lancom zu einem WAN gemacht und mittels NAT und Port-Forwarding können nun die IoT-Geräte im IoT-Netz auch Daten in mein internes Netz senden (MQTT an MQTT-Broker intern), was vorher nicht ging.

Was weiterhin nicht geht ist, dass die MQTT-Geräte im IoT-Netz auch an einen externen MQTT-Broker die Daten senden (HiveMQ). Das muss ich über den internen MQTT-Broker dann abbilden (zusätzliche Fehlerquelle).

IoT-WAN (10.82.10.0/24) <--NAT mit Port Forwarding--> | Internes LANCOM LAN (10.82.9.0/24 | <--NAT--> Public WAN (Internet)

Denke mal da gibt es keine einfache Lösung dafür.

VG

Uwe