Portforwardings gehen nicht und erfordern Neustart

[Jirka]

Hallo,

mit zwei verschiedenen 1781EW (FW 9.24-RU3) habe ich es jetzt gehabt, dass Portforwardings (UDP für VoIP/RTP) einfach nicht funktionieren. Es geht schlicht nicht. Man macht eine Stunde Troubleshooting, gibt dann auf, startet den Router neu und schon geht es! Hat das schon jemand ebenso beobachtet?
Der Ethernet-Trace zeigt, dass der LANCOM die Pakete auf WAN-Seite mit Port unreachable einfach abweißt. Keine Ahnung warum.
Bei dem einen Router kam das Problem wie aus heiterem Himmel, niemand hat den Router die letzten Wochen angefasst, bei dem anderen gingen ein paar Konfigurationsänderungen voraus, aber die waren auch schon ein paar Tage her. Das Problem wurde vermutlich nicht gleich erkannt, weil VoIP da noch im Testbetrieb ist.

Vielen Dank und viele Grüße,
Jirka

[Jirka]

Hallo,

so, aus heiterem Himmel (niemand hat den Router auch nur angefasst) geht das RTP-Portforwarding wieder nicht.
Router ist derzeit noch im Fehlerstatus. Der Fehler könnte also begutachtet werden. Ebenso könnte ich Traces machen, um den Fehler bzw. die Ursache eingrenzen zu können.
Was soll ich tun?

Ach ja, Firmware ist inzwischen die 9.24.0213. Gerät ist 4 Tage in Betrieb und eigentlich nur für die eigens für VoIP geschaffene 10-Mbit-Glasfaserleitung zuständig. Das Gerät ist also weder überlastet noch sonstwie besonders beansprucht.

Vielen Dank und viele Grüße,
Jirka

[Jirka]

Hallo,

keine Ideen?

Hier mal ein Ethernet-Trace mit dem ersten Paket, was reinkommt und dann mit port unreachable abgewiesen wird (IP-Adressen am Ende anonymisiert):

Code: Alles auswählen

[Ethernet] 2017/03/31 00:09:12,358
Received 214 byte Ethernet packet via DSL-1:
HW Switch Port      : WAN
IPv4 Hdr Checksum   : OK
IP Proto Checksum   : OK
-->IEEE 802.3 Header
Dest                : 02:a0:57:1b:75:eb (LANCOM(local-0) 1b:75:eb)
Source              : 50:c5:8d:a4:c6:a5
Type                : IPv4
-->IPv4 Header
Version             : 4
Header Length       : 20
ToS/DSCP            : (0x00) (Precedence 0) / (DSCP CS0/BE)
Total length        : 200
ID                  : 0
Fragment            : Offset 0
TTL                 : 50
Protocol            : UDP
Checksum            : 58241 (OK)
Src Address         : 217.24.x.y
Dest Address        : 213.144.x.y
-->UDP Header
Src Port            : 16612
Dest Port           : 10026
Length              : 180
Checksum            : 37916 (OK)
Body                : 80 08 01 2d 00 00 bb 81 ...-....
                      ef be ed fe 55 55 55 d5 ....UUU.
                      d5 54 d5 d4 d4 d4 d5 d5 .T......
                      d5 d5 55 55 55 54 d5 54 ..UUUT.T
                      54 55 55 d5 d5 d5 d5 d5 TUU.....
                      d5 d5 55 d5 d5 55 d5 55 ..U..U.U
                      d5 55 55 55 55 d5 55 55 .UUUU.UU
                      d5 d5 d5 d5 d5 d5 d5 d5 ........
                      d5 d5 d5 d5 d5 55 d5 d5 .....U..
                      d5 d5 d5 d5 55 d5 55 d5 ....U.U.
                      d5 d5 d5 d5 d5 d5 d5 d5 ........
                      55 d5 d5 d5 d5 55 d5 d5 U....U..
                      d5 d5 55 d5 d5 d5 d5 d5 ..U.....
                      d4 55 54 54 55 55 d5 55 .UTTUU.U
                      55 d5 d5 d5 d5 d5 d5 d5 U.......
                      d5 d5 d5 d5 d5 d5 d5 d5 ........
                      d5 55 d5 d5 d5 d5 d5 d5 .U......
                      d5 d5 d5 d5 d5 d5 d5 55 .......U
                      55 55 d5 d5 d5 d5 d5 55 UU.....U
                      d5 d5 d5 d5 d5 d5 d5 d5 ........
                      55 d5 55 55 d5 55 d5 d5 U.UU.U..
                      55 d5 d5 d5             U...

[Ethernet] 2017/03/31 00:09:12,374
Sent 70 byte Ethernet packet via DSL-1:
-->IEEE 802.3 Header
Dest                : 50:c5:8d:a4:c6:a5
Source              : 02:a0:57:1b:75:eb (LANCOM(local-0) 1b:75:eb)
Type                : IPv4
-->IPv4 Header
Version             : 4
Header Length       : 20
ToS/DSCP            : (0x00) (Precedence 0) / (DSCP CS0/BE)
Total length        : 56
ID                  : 30455
Fragment            : Offset 0
TTL                 : 60
Protocol            : ICMP
Checksum            : 25386 (OK)
Src Address         : 213.144.x.y
Dest Address        : 217.24.x.y
-->ICMP Header
Msg                 : port unreachable
Checksum            : 30 (OK)
Unused              : 0
Next-Hop MTU        : 0
-->IPv4 Header
Version             : 4
Header Length       : 20
ToS/DSCP            : (0x00) (Precedence 0) / (DSCP CS0/BE)
Total length        : 200
ID                  : 0
Fragment            : Offset 0
TTL                 : 50
Protocol            : UDP
Checksum            : 58241 (OK)
Src Address         : 217.24.x.y
Dest Address        : 213.144.x.y
-->UDP Header
Src Port            : 16612
Dest Port           : 10026
Length              : 180
Checksum            : 37916 (wrong, should be 5950)
Body                :

Und hier die Portforwardings:

Code: Alles auswählen

D-port-from D-port-to Protocol Peer       WAN-Address Intranet-Address Map-Port Active Comment            
======================================================----------------------------------------------------
5060        5060      UDP      VOIP_TELEM 0.0.0.0     192.168.10.190   0        Yes    SIP auf NEC        
10020       10040     UDP      VOIP_TELEM 0.0.0.0     192.168.10.191   0        Yes    RTP auf NEC VoIP-GW

Vielen Dank und viele Grüße,
Jirka

EDIT: Portforwarding-Tabelle ergänzt.

[Christoph_vW]

Ich habe das öfters, wenn ich unseren Exchange Server neu starte.
Das Port Forwarding (HTTPS) geht erst wieder wenn ich den LANCOM ebenfalls neu starte, oder das Port Forwarding abschalte und kurz danach wieder einschalte.

[Jirka]

Hallo zusammen,

in den Release-Notes (9.24.0212 RU4 ► 9.24.0261 RU5) habe ich Folgendes gefunden:

Der TFTP-Server im LANCOM Router konnte die Ports im Bereich von 8192 bis 16383 blockieren und gab diese erst nach einem Neustart des Gerätes wieder frei. In der Folge konnte es zu Problemen beim Port-Forwarding der genannten Ports kommen.

Damit sollte dieses mysteriöse Problem geklärt sein! Abenteuerlich. Ich habe ein paar Stunden damit zugebracht. Wie kam man drauf, dass das am TFTP liegt? Oder war's ein Zufallsfund?

Viele Grüße,
Jirka

[Koppelfeld]

Damit sollte dieses mysteriöse Problem geklärt sein! Abenteuerlich. Ich habe ein paar Stunden damit zugebracht. Wie kam man drauf, dass das am TFTP liegt? Oder war's ein Zufallsfund?

Geht noch abenteuerlicher, bei Geräten mit Hardware-NAT. Da haut es Dir auch unmotiviert die Portforwardings kaputt.

[Jirka]

Hallo Koppelfeld,

ja, aber das schaltest Du doch nicht an, oder?
Ich habe da bisher immer schon die Finger von gelassen, nachdem Alfred hier mal so ein paar Hintergründe dazu geschrieben hatte. Und ich meine die Geräte mit Hardware-NAT drin haben ja im Normalfall auch so genug Power, so dass ich aufs Hardware-NAT verzichten kann. Man muss sich ja nicht mehr Probleme machen, als man schon hat.

Viele Grüße,
Jirka

[Koppelfeld]

Hallo Jirka,

ja, aber das schaltest Du doch nicht an, oder?

Nein, natürlich nicht, denn ...

nachdem Alfred hier mal so ein paar Hintergründe dazu geschrieben hatte.

... den Beitrag habe ich auch gelesen. Alfred taugt definitiv nicht als Pressesprecher für Frau Merkel. Obwohl ich ihn für drei Wochen gerne auf diesem Posten sähe -- wir würden einiges gewahr.

Und ich meine die Geräte mit Hardware-NAT drin haben ja im Normalfall auch so genug Power, so dass ich aufs Hardware-NAT verzichten kann. Man muss sich ja nicht mehr Probleme machen, als man schon hat.

Hardwareunterstütztes Digitalaudio ist schon etwas, an das man sich gewöhnen kann.

[cpuprofi]

Hallo an Alle,

...Und ich meine die Geräte mit Hardware-NAT drin haben ja im Normalfall auch so genug Power, so dass ich aufs Hardware-NAT verzichten kann...

ist Euch schon mal aufgefallen, das ein 1783VA(W) keinen "Schalter" mehr für das Hardware-NAT hat? Beim1784 habe ich noch nicht geschaut, da noch OVP...

Grüße
Cpuprofi

[tiptel170]

Hallo,

ich habe hier gerade diese Berichte gelesen, denn bei mir gingen die Portforworts auch nicht mehr.
Hatte die neue Firmware 10.00.0170RU2 / 10.05.2017 in verdacht. Dies hat mich einige Stunden gekostet / Tage. Ärger mit der Telefonie, mal konnte ich den Teilnehmer hören oder er kann mich nicht hören.
Irre Fehler - dann hat sich die TK-Anlage nicht registiert, dann ging es wieder. Meine E-Mails konnte ich nicht mehr von Außen abholen - blockiert etc... War schon genervt!

Dann las ich es hier, nur durch Zufall, dass der Hardware NAT Problme macht. Diesen ausgeschaltet, siehe da es geht wieder alles

Denn beim 1781EW+ mit der neuen Firmware habe ich das Problem, dass das Auslesen mit dem Lanconfig über WAN exterm langsam oder garnicht geht. Und das ist defenitv seit der neuen FW.

Gruß tiptel170

[alf29]

ist Euch schon mal aufgefallen, das ein 1783VA(W) keinen "Schalter" mehr für das Hardware-NAT hat? Beim1784 habe ich noch nicht geschaut, da noch OVP...

Korrekt, im 1783/84 ist kein Switch mit Hardware-NAT mehr drin. Eben weil's mehr Ärger als Nutzen gebracht hat, und Qualcomm inzwischen von dem Feature auch nicht mehr so recht etwas wissen will und bei Problemen quasi keinen Support leistet...

Gruß Alfred