Lancom Router - Portforwarding

[Zaiga]

Hallo zusammen,

ich versuche einen Port im Lancom Router freizuschalten und auf einen Rechner im LAN weiterzuleiten.
Ich weiß nicht was ich falsch mache..

So sieht das ausgefühlte Port Forwarding aus.

Whr. muss ich eine Regel in der Firewall anlegen, ich verstehe aber nicht wie ich die Regel anlegen soll (habe es schon in verschiedenen Kombinationen versucht)
Nachfolgend das Menü:

Ich hab alle möglichen Kombinationen durchprobiert, es will einfach nicht funktionieren.

Danke Gruß!

 

[kamanu]

Mal abgesehen davon, dass in der Firewall Regel Quelle und Ziele fehlen (keine Ahnung ob die bei Lancom nötig sind, würde aber Sinn ergeben) - was für einen Internetanschluss hast du? Leider ist CGNat immer mehr verbreitet und lässt sowas erst gar nicht zu.

 

[chrigu]

Quelle: von welcher ip
ziel: wohin
das fehlt in deinen konfig Bild 2.
wobei der Sinn ein portforwarding im selben subnetz zu machen irgendwie nach einem xy Problem aussieht.

 

[Zaiga]

Die Konfig. in Bild Nr.2 ist nicht vollständig ausgefühlt weil ich nicht weiß wie

Bzgl. Portforwarding. Ich habe auf dem Rechner hinter dem Router Wireguard laufen, dieses will ich als VPN nutzen. Muss aber dazu den Port vom Router zum Server forwarden.

 

[Raijin]

Ich kenne mit mit LANCOM nicht aus, aber grundsätzlich sind folgende Komponenten beteiligt:

1) Firewall am Client (ausgehend) - Wenn das Client-Gerät schon sagt "ne, das blocke ich", geht nix.
2) Firewall am Client-Router (ausgehend) - Wenn der Router beim Client block, geht nix.
3) Provider des Clients - Wenn der Provider blockt, geht nix.
4) Provider des Servers - Wenn der Provider blockt, geht nix.
5) Öffentliche IP-Adresse am Server-Router - Wenn der Router beim Server keine öffentliche IP hat, geht nix.
6) Portweiterleitung am Server-Router - Wenn der Router beim Server keine Portweiterleitung hat, geht nix.
7) Firewall am Server-Router - Wenn der Router blockt, geht nix.
8) Firewall am Server - Wenn die Firewall am Ziel-Server blockt, geht nix.
9) Anwendung auf dem Server - Wenn die Anwendung auf dem Server nicht läuft oder blockt, geht nix.



1-4 sind normalerweise kein Problem.

Punkt 5, die öffentliche IP-Adresse, hängt von der Art des Internetanschlusses ab und davon ob der Tarif mit einer eigenen öffentlichen IP ausgestattet ist oder ob DS-Lite/CGN anliegt. Bei den letzten beiden steht der Router effektiv im lokalen Netzwerk des Providers und nicht im Internet bzw. nur mittels IPv6 und nicht mit IPv4.

Für 6 und 7 ist der Router des Servers verantwortlich. Die Portweiterleitung im Screenshot sieht ok aus wobei WireGuard meines Wissens nach ausschließlich UDP einsetzt, das Protokoll also auf UDP-only gestellt werden könnte. Beim zweiten Screenshot muss hier die Quell-IP (leer oder ggfs 0.0.0.0 für alles IPs) eingegeben werden, bei Protokoll eben das Protokoll aus der Weiterleitung (TCP+UDP oder eben UDP-only) und der Ziel-Port. Ausschlaggebend ist hier der interne bzw. der map Port aus der Weiterleitung, da die Firewall nach DNAT (=Portweiterleitung) aktiv wird, also mit bereits veränderten Ziel-Daten. Im vorliegenden Fall wird der Port aber 1:1 gemapped und dann kommt da eben 51820 hin. Das Ziel ist der lokale Server und als Action eben Allow oder Accept wählen, je nachdem wie LANCOM das nennt.

Bei 8 bzw. 9 scheitert es hingegen am häufigsten, weil bei nicht funktionierender Portweiterleitung meistens die Weiterleitung selbst als Ursache gesehen wird, auch wenn sie in den allermeisten Fällen pflichtgetreu weiterleitet, wenn sie denn korrekt konfiguriert ist. Allerdings muss aber auch das Ziel der Weiterleitung die Verbindung akzeptieren. Unter Windows müsste man zunächst prüfen ob die Firewall auf dem öffentlichen oder dem privaten Profil läuft. Ersteres ist für öffentliche Netzwerke (Hotel-WLAN) gedacht und macht alle Ports zu. Das private Profil ist für das heimische Netzwerk gedacht und nur hier sollte man entsprechende Ausnahmen eintragen, in den eingehenden Regeln. Entweder explizit UDP 51820 erlauben oder die gesamte wireguard.exe (oder wie auch immer die exe heißt). Läuft der Server mit Linux, muss man dies alles natürlich mit iptables/nftables oder einem FW-Helper wie zB ufw konfigurieren.

Zu guter Letzt muss natürlich die jeweilige Anwendung (wireguard) auch laufen und auf Verbindungen warten, auf dem korrekten Listen-Port (=der interne/map Port aus der Weiterleitung). Unter Windows mit netstat -ano und unter Linux mit netstat -tulpen zu prüfen.

 

[Zaiga]

Vielen dank für den ausführlichen Beitrag! Ich glaube der Port wird jetzt forwarded, jedenfalls kriege ich einen Ping!

 

[Raijin]

Das eine hat mit dem anderen nichts zu tun. Ping ist ICMP und somit weder TCP noch UDP und kennt vor allem keine Ports, weil es noch nicht mal auf derselben OSI-Schicht läuft. Eine Portweiterleitung kannst du nur testen, wenn du Pakete an deine WAN-IP schickst, die explizit dem Matching der Portweiterleitung entsprechen. Also keine Pings, keine TCP-Pakete bei UDP-Weiterleitungen, keine anderen Ports, sondern exakt zB UDP 51820 und sonst nix.

Schließlich kannst du auch nicht das Festnetztelefon deiner Oma testen, indem du ihr eine SMS auf's Handy schickst.

Ein Ping auf deine vermeintliche öffentliche IP zeigt lediglich, dass auf dieser IP irgendetwas auf einen Ping reagiert. Im Falle eines Internetanschlusses mit CGN (Carrier Grade NAT) muss es noch nicht mal dein Router sein, weil dein Router sich gar nicht selbst im Internet befindet, sondern im "lokalen" Netzwerk des Providers, dessen großer Router im Rechenzentrum tatsächlich hinter der IP bei "wieistmeine.ip" steckt - und die du ggfs auch anpingen kannst, während Portweiterleitungen in diesem Szenario niemals funktionieren würden, weil dein Router von außen gar nicht erreichbar wäre.

Ob eine Portweiterleitung funktioniert oder nicht kannst du daher nur mit Paketen testen, die den weiterleitungsspezifischen Eigenschaften entsprechen. In erster Linie wäre das natürlich die jeweilige Anwendung um die es geht, also in diesem Fall mit einem WireGuard-Client einen VPN-Tunnel von außen herstellen. Alternativ gibt es Porttester im www, die sogenannte Probes schicken, kurze, quasi inhaltslose Verbindungsanfragen auf zB UDP 51820. Wenn irgendetwas außer "Timeout" oder "Denied" zurückkommt, antwortet etwas auf diesem Port und der Porttester sagt "offen".