Portforwarding funktioniert nicht richtig bei 7170

[theTransporter]

Hallo, ich habe ein 7170 Firmware-Version 29.04.59freetz-devel-2586M.
Unter anderem habe ich die AVM Firewall integriert.

Ich möchte gerne den UDP Port 20450 auf die FrtitzBox (IP: 192.168.25.1) forwarden, da dort ein kleiner Server auf Anfragen wartet. Dazu habe ich in der ar7.cfg folgenden Eintrag vorgenommen:

"udp 0.0.0.0:20450 0.0.0.0:20450 0 # CS"

In der AVM Firewall taucht die Regel auch richtig auf.
Wenn ich nun mit einem Client übers I-Net versuche eine Kommunikation aufzubauen, klappt das nicht. Der Client kann sich nicht verbinden.
Aus dem lokalen netz funktioniert es aber.

Nun habe ich gerade mal mit

netstat -na

auf die Box geschaut.
Dort taucht der Port auch auf, allerdings so:

udp        0      0 192.168.25.1:20450      0.0.0.0:*

Mich hat es stutzig gemacht, dass die IP der fritzBox mit aufgeführt ist, da ich diese nirgends angegeben habe und die IP auch bei sonstigen freigaben nicht auftaucht.
Ich habe eine weitere Freigabe auf die FritzBox, welche einwandfrei funktioniert.

Des weiteren macht mich folgendes stutzig.
netsat -na sagt mir folgendes:

tcp        0      0 192.168.25.1:20451      0.0.0.0:*               LISTEN

In der arf.cfg steht aber

"udp 0.0.0.0:20451 0.0.0.0:20451 0 #Server1"

Ich hoffe mir kann jemand weiter helfen.

EDIT:
Ich hänge nochmal die gesamte Liste vom netstat an, vielleicht ist das behilflich.

/var/mod/root # netstat -na
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address         State
tcp        0      0 0.0.0.0:2050            0.0.0.0:*               LISTEN
tcp        0      0 192.168.25.1:20451      0.0.0.0:*               LISTEN
tcp        0      0 0.0.0.0:5060            0.0.0.0:*               LISTEN
tcp        0      0 0.0.0.0:49000           0.0.0.0:*               LISTEN
tcp        0      0 0.0.0.0:8080            0.0.0.0:*               LISTEN
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN
tcp        0      0 0.0.0.0:81              0.0.0.0:*               LISTEN
tcp        0      0 0.0.0.0:82              0.0.0.0:*               LISTEN
tcp        0      0 127.0.0.1:1011          0.0.0.0:*               LISTEN
tcp        0      0 0.0.0.0:1012            0.0.0.0:*               LISTEN
tcp        0      0 0.0.0.0:21              0.0.0.0:*               LISTEN
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN
tcp        0      0 0.0.0.0:23              0.0.0.0:*               LISTEN
tcp        0      0 127.0.0.1:8888          0.0.0.0:*               LISTEN
tcp        0      0 192.168.25.1:21         192.168.25.60:52653     ESTABLISHED
tcp        0      0 127.0.0.1:1012          127.0.0.1:3191          ESTABLISHED
tcp        0      0 127.0.0.1:3191          127.0.0.1:1012          ESTABLISHED
tcp        0      1 192.168.25.1:2166       192.168.25.60:14013     SYN_SENT
tcp        0      0 127.0.0.1:3877          127.0.0.1:1011          ESTABLISHED
tcp        0    132 192.168.25.1:23         192.168.25.60:52660     ESTABLISHED
tcp        0      0 127.0.0.1:1011          127.0.0.1:3877          ESTABLISHED
tcp        0      0 192.168.25.1:1012       192.168.25.20:1024      ESTABLISHED
udp        0      0 0.0.0.0:2048            0.0.0.0:*
udp        0      0 0.0.0.0:2049            0.0.0.0:*
udp        0      0 0.0.0.0:2050            0.0.0.0:*
udp        0      0 0.0.0.0:2051            0.0.0.0:*
udp        0      0 0.0.0.0:2052            0.0.0.0:*
udp        0      0 0.0.0.0:2053            0.0.0.0:*
udp        0      0 0.0.0.0:7077            0.0.0.0:*
udp        0      0 127.0.0.1:8998          0.0.0.0:*
udp        0      0 0.0.0.0:53              0.0.0.0:*
udp        0      0 127.0.0.1:8004          0.0.0.0:*
udp        0      0 0.0.0.0:5060            0.0.0.0:*
udp        0      0 192.168.25.1:20450      0.0.0.0:*
udp        0      0 0.0.0.0:20455           0.0.0.0:*
udp        0      0 192.168.25.1:999        0.0.0.0:*
udp        0      0 0.0.0.0:20457           0.0.0.0:*
udp        0      0 0.0.0.0:20458           0.0.0.0:*
udp        0      0 0.0.0.0:1900            0.0.0.0:*
udp        0      0 0.0.0.0:1900            0.0.0.0:*
udp        0      0 0.0.0.0:1900            0.0.0.0:*
raw        0      0 0.0.0.0:2               0.0.0.0:*               7
raw        0      0 0.0.0.0:2               0.0.0.0:*               7
raw        0      0 0.0.0.0:2               0.0.0.0:*               7
Active UNIX domain sockets (servers and established)
Proto RefCnt Flags       Type       State         I-Node Path
unix  2      [ ]         DGRAM                      1289 /var/tmp/to_wpa_hidden_sock
unix  2      [ ]         DGRAM                      1291 /var/tmp/wpa_debug_sock
unix  2      [ ]         DGRAM                      1129 /var/tmp/me_logic.ctl
unix  2      [ ]         DGRAM                      2155 /var/tmp/me_voipd.ctl
unix  2      [ ]         DGRAM                      1131 /var/tmp/me_ctlmgr.ctl
unix  2      [ ]         DGRAM                      1673 /var/tmp/me_multid.ctl
unix  2      [ ]         DGRAM                      2205 /var/tmp/me_igdd.ctl
unix  2      [ ]         DGRAM                      1954 /var/tmp/me_dsld.ctl
unix  2      [ ]         DGRAM                      2505 /var/tmp/me_usermand.ctl
unix  2      [ ACC ]     STREAM     LISTENING       2029 /var/tmp/pbctrl
unix  2      [ ACC ]     STREAM     LISTENING       2031 /var/tmp/pb_event
unix  2      [ ACC ]     SEQPACKET  LISTENING       2037 /var/tmp/foncontrol
unix  2      [ ]         DGRAM                      2040 /var/tmp/me_foncontrol.ctl
unix  2      [ ]         DGRAM                      2044 /var/tmp/me_phonebook.ctl
unix  3      [ ]         STREAM     CONNECTED       2281 /var/tmp/pb_event
unix  3      [ ]         STREAM     CONNECTED       2280 /var/tmp/pbctrl
unix  3      [ ]         STREAM     CONNECTED       2279
unix  3      [ ]         STREAM     CONNECTED       2278
unix  3      [ ]         STREAM     CONNECTED       2064 /var/tmp/pb_event
unix  3      [ ]         STREAM     CONNECTED       2063 /var/tmp/pbctrl
unix  3      [ ]         STREAM     CONNECTED       2062
unix  3      [ ]         STREAM     CONNECTED       2061

 

[RalfFriedl]

Das Programm netstat zeigt nicht die Port-Weiterleitung der Box, sondern die tatsächlich geöffneten Ports. Das Problem ist, daß Dein Programm sich nur an die lokale Adresse bindet und daher nur unter der lokalen Adresse ansprechbar ist und nicht auf allen Adressen.

Je nachdem, welches Programm Du verwendest, mußt Du in dessen Konfiguration nachsehen, ob/wie man das ändern kann.

 

[theTransporter]

Da müsste ich nochmal schauen, ob der Server vielleicht wirklich nur auf interne Anfragen reagiert.
Ist das eine Vermutung von dir oder kannst du das irgendwo heraus erkennen?


Mich hat halt gewundert, dass so viele Ports offen sind, obwohl ich nur vier forwardings eingerichtet habe.

 

[olistudent]

Das sind nicht die offenen Ports, sondern die Ports auf denen ein Server hört. Das hat nichts damit zu tun, ob du die Ports von außen auch erreichen kannst. Dazu müsstest du von außen (z.B. mit nmap) einen Portscan auf die Box machen.

MfG Oliver

 

[theTransporter]

OK.
Was ist denn zB mit dem zweiten Eintrag von oben (Port 20451).
Das habe ich auch bereits in meinem ersten Post geschrieben. Sieht in der Liste anders aus als konfiguriert. Ist das nun richtig oder falsch?
Für mich siehts falsch aus.

 

[RalfFriedl]

Ist das eine Vermutung von dir oder kannst du das irgendwo heraus erkennen?

Auch wenn manche meinen, daß wir die allwissende Kristallkugel hätten, ist dem meistens nicht so.
Wenn Du Dir die Ausgabe von netstat anschaust, wirst Du feststellen, daß bei manchen Ports davon eine IP-Adrese steht (192.168.25.1:20451) und bei anderen nicht (0.0.0.0:5060).

Mich hat halt gewundert, dass so viele Ports offen sind, obwohl ich nur vier forwardings eingerichtet habe.

Wie Oliver bereits geschrieben hat, haben die offenen Ports nichts mit Forwarding zu tun. Offene Ports gibt es auch auf normalen Systemen, die nicht als Router genutzt werden und folglich kein Forwarding kennen.

Ist das nun richtig oder falsch?

Falsch ist es dann, wenn es anders als gewünscht ist. Da Du bisher wenig dazu geschrieben hast, was Du da erwartest, ist das schwer zu beurteilen.
Wenn Da aber möchtest, daß der Server von außen erreichbar ist, dann ist es falsch, wenn der Port an die lokale IP-Adresse gebunden wird.

Kannst Du übrigens mal erläutern, was das Ganze mit Freetz zu tun hat?

 

[olistudent]

Naja, er hat Freetz auf der Box. :mrgreen:

MfG Oliver

 

[theTransporter]

Ich denke es hat mit Freetz zun, weil ich die Forwarding Regeln mit Hilfe des AVM-Firewall-Paketes eingerichtet habe. Schlag mich, aber verkauf nicht wenn meine Annahme falsch war.

Wenn Da aber möchtest, daß der Server von außen erreichbar ist, dann ist es falsch, wenn der Port an die lokale IP-Adresse gebunden wird.

Das beschreibt doch genau mein Problem und ich weiß jetzt, wie ich es erkenne.
Ich dachte ich hätte beschrieben was ich möchte.

Ich möchte gerne den UDP Port 20450 auf die FrtitzBox (IP: 192.168.25.1) forwarden, da dort ein kleiner Server auf Anfragen wartet.

Wenn ich nun mit einem Client übers I-Net versuche eine Kommunikation aufzubauen, klappt das nicht. Der Client kann sich nicht verbinden.
Aus dem lokalen netz funktioniert es aber.

Und was ich habe, habe ich auch geschrieben, nämlich in der ar7.cfg

"udp 0.0.0.0:20450 0.0.0.0:20450 0 # CS"

und als Ergebnis der netstat Abfrage

udp 0 0 192.168.25.1:20450 0.0.0.0:*

Jetzt ist aber klar, derr der Server nur aus dem LAN erreichbar ist, aufgrund der eingetragenen IP Adresse (HAbe ich wieder was gelernt).
Als nächstes stellt sich natürlich die Frage, wieso die IP dort steht und wie ich das ändern kann. Könntet ihr mir dabei nochmal behilflich sein, bitte?

 

[KuniGunther]

Wenn Da aber möchtest, daß der Server von außen erreichbar ist, dann ist es falsch, wenn der Port an die lokale IP-Adresse gebunden wird.

Sorry, diese generelle Aussage halte ich so für falsch. Der Server soll ja über Portforwarding erreicht werden und Sinn des Portforwarding ist es, Server von außen zu erreichen, die ihre Ports nur im lokalen Netz offen haben.

Der Server muss seine Ports an die lokale Adresse binden und der Portforwarder muss dafür sorgen, dass von außen kommende Pakete an die lokale Adresse weitergeleitet werden. Ob netstat einen lauschenden Port auf der öffentlichen IP anzeigt oder nicht, hängt davon ab, wie das Portforwarding implementiert ist.

 

[RalfFriedl]

Was netstat anzeigt, hängt nicht davon ab, wie das Port-Forwarding implementiert ist. Das Programm netstat gibt es auch auf Rechnern, die selbst keine Router sind und folglich kein Port-Forwarding haben.

Es stimmt aber, daß es möglicherweise auch funktionieren kann, wenn der Server an die lokale Adresse gebunden ist, wenn das Port-Forwarding von AVM so funktioniert, daß es das unterstützt. Dafür käme es darauf an, ob lokal von der Box generierte Pakete auf dem Weg nach draußen auch durch die NAT-Umsetzung gehen oder nicht. Außerdem hat sich anscheinend bei AVM etwas in der Implementierung geändert, zumindest gibt es Berichte, daß Port-Forwarding auf lokale Adressen nicht mehr funktionieren würden. Die sicherste Möglichkeit, das herauszufinden, ist, es auszuprobieren.

@theTransporter
Wie man beeinflussen kann, an welche Adresse sich der Server bindet, hängt von dem Server ab. Und Du hast bisher nicht gesagt, um was für einen Server es sich handelt (oder ich habe es übersehen).

 

[KuniGunther]

Was netstat anzeigt, hängt nicht davon ab, wie das Port-Forwarding implementiert ist.

Doch. Was netstat anzeigt sind offene Ports auf denen gelauscht wird. Ob netstat etwas anzeigt, hängt also davon ab, ob der Forwarder (unwahrscheinlich, aber möglich) aktiv auf dem Port lauscht. Für user space forwarder wie udptunnel oder socat ist das der Fall.

Es stimmt aber, daß es möglicherweise auch funktionieren kann, wenn der Server an die lokale Adresse gebunden ist, wenn das Port-Forwarding von AVM so funktioniert, daß es das unterstützt.

Darauf kommt es zwar an, aber das war bisher nicht der Punkt. theTransporter will einen lokalen Server per Forwarding betreiben und hat Portforwarding vorausgesetzt. Die Aussage, die dann gemacht wurde war, dass es nicht korrekt ist, wenn netstat nur eine Bindung auf eine lokale Adresse anzeigt und er von außen erreichbar sein will. Und diese Aussage stimmt nicht, da die Weiterleitung auf den lokalen Port laut Frage vom Portforwarder übernommen werden soll. Und die Schlussfolgerung von theTransporter

Und was ich habe, habe ich auch geschrieben, nämlich in der ar7.cfg

udp 0.0.0.0:20450 0.0.0.0:20450 0 # CS

und als Ergebnis der netstat Abfrage

udp 0 0 192.168.25.1:20450 0.0.0.0:*

ist auch nicht korrekt, da letzteres nicht die Folge des Eintrages in ar7.cfg ist, sondern die Folge des gestarteten Servers. Ebenso die weitere Schlussfolgerung, dass er _trotz_ Portforwarding eine Bindung an die externe IP braucht falsch.

Dafür käme es darauf an, ob lokal von der Box generierte Pakete auf dem Weg nach draußen auch durch die NAT-Umsetzung gehen oder nicht. Außerdem hat sich anscheinend bei AVM etwas in der Implementierung geändert, zumindest gibt es Berichte, daß Port-Forwarding auf lokale Adressen nicht mehr funktionieren würden.

Das ist genau der Punkt, aber der wurde bisher an keiner Stelle erwähnt. Die entsprechende Schlussfolgerung wäre dann, auf das Portforwarding zu verzichten und stattdessen(!) an die richtige Adresse zu binden. Aber bitte nicht beides mischen!

 

[theTransporter]

Also ich kann euch noch so halb folgen
Fakt ist aber tatsächlich, dass es in der Config meines Servers (MPCS) einen Eintrag gibt, andem diesem eine IP-Adresse zugewiesen wird. Dort habe ich natürlich die IP der FB eingetragen.
Das hatte aber die von euch erläuterte Konsequenz, dass der Server nur noch auf Anfragen aus dem LAN reagiert hat.
Diesen Eintrag habe ich in der Konfiguration nun entfernt und es funktioniert.

Auch wenn es jetzt ein eher blöder Fehler meinserseits war, der einfach auf Unwissenheit beruht, habe ich hier wieder eine Menge dazugelernt.

Letztendlich wäre ich nie auf den fehler gekommen, wenn ihr nicht die entsprechenden Anmerkungen gemacht hättet.

Dafür danke ich euch vielmals!

 

[McNetic]

Ergänzung: Wenn man keine explizite Adresse angibt, lauschen manche Server nur auf dem Interface mit der lokalen Adresse (127.0.0.1), viele aber auf allen verfügbaren Interfaces, was offenbar hier auch der Fall ist.

 

[RalfFriedl]

Ob netstat etwas anzeigt, hängt also davon ab, ob der Forwarder (unwahrscheinlich, aber möglich) aktiv auf dem Port lauscht. Für user space forwarder wie udptunnel oder socat ist das der Fall.

Richtig, user space forwarder werden in netstat angezeigt, weil es sich bei diesen letztlich um ganz normale Anwendungsprogramme handelt.
Die Port-Weiterleitung von AVM ist aber kein user space forwarder, sondern irgendwo im kdsld Modul enthalten, vermutlich mit Hilfe vom dsld Prozeß.

Und anscheinend war das Problem tatsächlich, daß der Port an die lokale IP-Adresse gebunden wurde.