VoIP Pakete größer als MTU

5 years ago

Hallo,

 

ich betreibe eine FritzBox hinter einer Firewall und habe die Ports entsprechend weitergeleitet. Die Installation hat auch bis vor ein paar Tagen wunderbar funktioniert. Seit letzter Woche sind allerdings keine eingehenden Anrufe mehr möglich und wenn ich mir den Paketfluss beim Gesprächsaufbau von außen anschaue, sehe ich:

 

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on pppoe0, link-type NULL (BSD loopback), capture size 262144 bytes
21:29:56.748113 IP 217.0.29.32.5060 > 84.151.83.18.55391: UDP, bad length 1679 > 1464
21:29:57.248856 IP 217.0.29.32.5060 > 84.151.83.18.55391: UDP, bad length 1679 > 1464
21:29:58.249849 IP 217.0.29.32.5060 > 84.151.83.18.55391: UDP, bad length 1679 > 1464
21:30:00.250825 IP 217.0.29.32.5060 > 84.151.83.18.55391: UDP, bad length 1679 > 1464
21:30:04.251742 IP 217.0.29.32.5060 > 84.151.83.18.55391: UDP, bad length 1679 > 1464
21:30:12.252660 IP 217.0.29.32.5060 > 84.151.83.18.55391: UDP, bad length 1679 > 1464

 

Die Anfrage wird in einem Paket mit einer Größe größer 1452 bytes geschickt. Selbst 1492 oder gar die üblichen 1500 bytes der MTU werden nicht berücksichtigt. Fragmentiert ist das Paket auch nicht, sonst würde das System zwei fragmentierte Pakete weiterleiten.

 

Interessant ist das die Pakete auch nicht über PPPoE fragmentiert geliefert werden:

 

# tcpdump -pqni igb2.178 '(pppoes and udp and port 5060) or (udp and port 5060)'
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on igb2.178, link-type EN10MB (Ethernet), capture size 262144 bytes
21:41:17.176015 PPPoE [ses 0x303c] IP 217.0.29.32.5060 > 84.151.83.18.55391: UDP, bad length 1678 > 1464
21:41:17.676301 PPPoE [ses 0x303c] IP 217.0.29.32.5060 > 84.151.83.18.55391: UDP, bad length 1678 > 1464
21:41:18.677444 PPPoE [ses 0x303c] IP 217.0.29.32.5060 > 84.151.83.18.55391: UDP, bad length 1678 > 1464
21:41:20.678230 PPPoE [ses 0x303c] IP 217.0.29.32.5060 > 84.151.83.18.55391: UDP, bad length 1678 > 1464
21:41:24.679234 PPPoE [ses 0x303c] IP 217.0.29.32.5060 > 84.151.83.18.55391: UDP, bad length 1678 > 1464
21:41:32.680256 PPPoE [ses 0x303c] IP 217.0.29.32.5060 > 84.151.83.18.55391: UDP, bad length 1678 > 1464

 

Man sieht schön wie die Telekom hier viel zu große Pakete über die Leitung schickt, welche dann von der Firewall zu recht blockiert werden...

 

Was machen wir denn da um die Geschichte wieder gangbar zu machen?

 

Cu

 

1263

0

17

    • 5 years ago

      wenn das Paket unfragmentiert zu groß wären, würde es dies gar nicht über das Modem der Fritzbox schaffen.

       

      ich würde mal den Paketsniffer auf dem WAN und LAN Interface der Fritzbox laufen lassen.

      0

      16

      Answer

      from

      5 years ago

      fdi

      @Trimegon ich habe auch keine Standardkonfiguration, kann aber sowohl eingehend und ausgehend jederzeit telefonieren. Also überprüfe nochmal deine Konfigurationen. Vielleicht auch nur mit der FritzBox für Alles. Wenn das ein Grundsatzproblem wäre, dann könnte Keiner mehr angerufen werden, ist aber nicht so.

      @Trimegon 

       

      ich habe auch keine Standardkonfiguration, kann aber sowohl eingehend und ausgehend jederzeit telefonieren. Also überprüfe nochmal deine Konfigurationen. Vielleicht auch nur mit der FritzBox für Alles. Wenn das ein Grundsatzproblem wäre, dann könnte Keiner mehr angerufen werden, ist aber nicht so.

      fdi

      @Trimegon 

       

      ich habe auch keine Standardkonfiguration, kann aber sowohl eingehend und ausgehend jederzeit telefonieren. Also überprüfe nochmal deine Konfigurationen. Vielleicht auch nur mit der FritzBox für Alles. Wenn das ein Grundsatzproblem wäre, dann könnte Keiner mehr angerufen werden, ist aber nicht so.


      Dir ist schon klar das ich Pakete in einer Größe bis 1908 Bytes EMPFANGE und nicht versende.

       

      Die Gegenseite handelt mit mir eine maximale MTU über PPPoE von 1492 Bytes via LCP aus und sendet mir dann 1908 Byte große Pakete.

       

      Was ich da überprüfen soll ist mir nicht ganz klar.

       

      0

      Answer

      from

      5 years ago

      Naja, die Ursache muss ja irgendwie in deinem Setup liegen, wenn es sonst funktioniert, aber wenn du das ja so sicher ausschließt, dann eben nicht. Kannst es ja dann mal in einem Forum zu deiner Firewall zur Sprache bringen, vielleicht bekommst du da dann Hilfe.

       

      Bin da mal raus.

      Answer

      from

      5 years ago

      fdi

      Naja, die Ursache muss ja irgendwie in deinem Setup liegen, wenn es sonst funktioniert, aber wenn du das ja so sicher ausschließt, dann eben nicht. Kannst es ja dann mal in einem Forum zu deiner Firewall zur Sprache bringen, vielleicht bekommst du da dann Hilfe. Bin da mal raus.

      Naja, die Ursache muss ja irgendwie in deinem Setup liegen, wenn es sonst funktioniert, aber wenn du das ja so sicher ausschließt, dann eben nicht. Kannst es ja dann mal in einem Forum zu deiner Firewall zur Sprache bringen, vielleicht bekommst du da dann Hilfe.

       

      Bin da mal raus.

      fdi

      Naja, die Ursache muss ja irgendwie in deinem Setup liegen, wenn es sonst funktioniert, aber wenn du das ja so sicher ausschließt, dann eben nicht. Kannst es ja dann mal in einem Forum zu deiner Firewall zur Sprache bringen, vielleicht bekommst du da dann Hilfe.

       

      Bin da mal raus.


      Klar schließe ich das aus. Oder denkst Du ernsthaft das die Firewall die Pakete künstlich aufbläst? Und dann auch nur die auf UDP/5060?

       

      Oder das die Fragmentierung nur bei diesem einen Paket gezielt versagt?

       

      Die Logs, welche ich vorher geschickt habe, zeigen die PPPoE-Pakete samt Inhalt. Da wurde - sofern notwendig - noch gar keine Defragmentierung durchgeführt weil die Pakete den Kernel und den IP-Stack noch gar nicht erreicht haben.

       

      Einfach mal drüber nachdenken...

       

       

      0

      Unlogged in user

      Answer

      from

    Unlogged in user

    Ask

    from

    This could help you too

    Loading...
    Loading...
    Loading...
    Loading...
    Loading...
    Loading...
    Loading...
    Loading...
    Loading...
    Loading...
    Loading...
    Loading...
    Loading...
    Loading...
    Loading...
    Loading...
    Loading...
    Loading...
    Loading...
    Loading...
    Loading...
    Loading...
    Loading...
    Loading...
    Loading...
    Loading...
    Loading...
    Loading...
    Loading...
    Loading...
    Loading...
    Loading...
    Loading...
    Loading...
    Loading...