NATs are good

… also, meistens.

Ich hab’ derzeit ein sonderbares Problem. Kabel-Internet (Businessvariante: 1x IPv4 (MTU 1500), kein IPv6), daran eine FritzBox 6360.

Im LAN steht ein Asterisk 13, der über einen SIP-Provider, nennen wir ihn E, ausgehende Telefonie inkl. CLIP (no screening) macht. Am Asterisk »angeschlossen« sind u. a. Snom 3xx und Cisco 99×1.

Bislang war alles schick, die Telefone telefonierten – dank CLIP (no screening) – mit der alten Nummer raus, und es waren somit ausgehend schon mal mehr parallele Gespräche möglich als die beiden ISDN-B-Kanäle (jetzt nur noch inbound genutzt) hergaben.

(ISDN kam über eine FritzBox 7272 in den Asterisk, da ISDN und Asterisk heute keinen Spaß mehr machen.)

Seit dieser Woche habe ich das Phänomen, daß ausgehende Telefonate über Anbieter E keinen inbound audio channel haben. Sprich: ich wähle raus und … höre nix. Werde ich angerufen (über SIP, d. h. eben jenen Asterisk), ist alles schick.

Ich habe es soweit nun verifiziert, daß tatsächlich kein RTP-Stream vom Anbieter zu meinem Asterisk aufgebaut wird. Wieso, weshalb, warum: äh, nächste Frage?

Nun hatte ich NAT im Verdacht und die – wie gesagt bislang funktionalen – Einstellungen des Asterisk in dieser Hinsicht von links auf rechts auf oben und wieder auf links gezogen, denn ich glaube nicht mehr, daß es eine NAT-Einstellung im Asterisk ist:

  • Nutze ich einen anderen Asterisk zum rauswählen (also mein Asterisk wählt über einen anderen raus, dessen Context dann über Anbieter E geht), gibt es kein Problem.
  • Konfiguriere ich Anbieter E als SIP-Trunk auf einer 7490 im LAN (LAN-Client-Modus), und verbinde den Asterisk über einen SIP-Account mit der 7490 und nutze dies zum rauswählen, gibt es kein Problem (bis auf den Verlust von CLIP (no screening)).
  • Nutze ich einen anderen Anbieter, nennen wir ihn P, mit den gleichen NAT-Einstellungen, gibt es kein Problem.

Für ›NAT ist Dein Problem‹ spricht sicher einiges; dagegen aber die Funktion mit anderem Anbieter/Asterisk (jene Verbindungen von diesem Asterisk müssen genauso durch das NAT der 6360) und irgendwie auch die Funktion über die 7490. Für Einstellungsprobleme auf Asterisk-Ebene – ggf. in Verbindung mit NAT – wiederum spricht die Funktion des SIP-Zugangs bei E via 7490; dagegen aber die Funktion mit P oder einem anderen Asterisk.

*kopfkratz* Irgendwer ‘ne Idee?

5 thoughts on “NATs are good

  1. Wenn sich zu Hause nichts geändert hat würde ich auf die MTU tippen. Das evtl. ein Router dazwischen geändert wurde.

    Hatte so ein Problem bisher allerdings nur im V6 Bereich, wo früher ja sehr viele Tunnel eingesetzt wurden.

    Wobei, vor vier Wochen hatte ich das MTU Problem im zusammenspiel mit einem Windows Rechner (IPSec auf einem Raspberry als Router). Das interessante dabei Android Handys kamen damit klar. Bei Windows musste ich die MTU erst runter setzen damit da was ging. Der Fehler lag letzt endlich in dem falsch konfigurierten Linux.

    Evtl. hilft dir der gedanken Anstoß

    • Ich glaube nicht, daß der *Nichtaufbau* einer RTP-Verbindung E->mein Asterisk was mit der MTU zu tun hat, die, wie ich auch erwähnte, lt. tracepath bei 1500 liegt ;).

      Beim (Überraschung!) gleichen Anbieter, aber Privatkundentarif (DS-Lite), sieht das mit der MTU in der Tat schlecht aus:

      wusel@ysabell:~$ tracepath 148.251.168.166
       1?: [LOCALHOST]                                         pmtu 1500
       1:  192.168.5.33                                          3.251ms 
       1:  192.168.5.33                                          4.410ms 
       2:  192.168.175.1                                         3.205ms 
       3:  192.0.0.2                                             3.148ms pmtu 1460
       3:  no reply
       4:  84.116.197.141                                       20.633ms 
       5:  84.116.196.194                                       25.529ms asymm 10 
       6:  de-fra01b-rc1-ae17-0.aorta.net                       26.589ms asymm  9 
       7:  de-fra01b-ri1-ae0-0.aorta.net                        26.387ms 
       8:  ae9-0.fra10.core-backbone.com                        24.502ms 
       9:  ae6-2011.nbg40.core-backbone.com                     26.464ms asymm 10 
      10:  core-backbone-100g-nbg.hetzner.de                    29.797ms 
      11:  core11.nbg1.hetzner.com                              25.996ms 
      12:  core24.fsn1.hetzner.com                              30.493ms 
      13:  ex9k2.rz19.hetzner.de                                25.575ms 
      14:  dorfl.uu.org                                         28.912ms 
      15:  mail.guetersloh.freifunk.net                         27.021ms reached
           Resume: pmtu 1460 hops 15 back 15 
    • Nope. E ist (u. a). ein SIP (-Trunking) -Anbieter; ich gehe auch davon aus, daß der Name nichts zur Sache beiträgt, sonst würde ich Roß und Reiter nennen.

  2. moin

    codec?
    klappt die Aushandlung?
    selbst o2-dtag und Vodafone-o2 haben sporad. Probleme.

    oder Ports
    welche Ports werden für die rtp streams genutzt?
    jeweils beim fehlerhaften E und beim funktionierenden P
    sip trace?
    was sagt wireshark?

    was ist, wenn du den sipaccount direkt anrufst?
    also nicht die rufnummer, sondern direkt sip account zu sipaccount?

    zb bei einer Fritzbox sind im Router Modus und im IP Client Modus die Ports für rtp unterschiedlich,
    musste ich auch etwas suchen, als ich die o2 fritze hinter der sophos utm hatte.
    Verbindungsaufbau war immer ok, aber immer wieder mal einseitige Verständigung.

    Gruß Ingo

  3. Des Rätsels Lösung: ICE/STUN. Zu E wurde STUN benutzt (in [general] per icesupport=yes aktiviert), zu P nicht — warum auch immer. Nach dem auskommentieren von icesupport=yes klappt’s nun auch wieder mit E und ich kann mit den Umweg über die Fritte sparen ;)

    Faktisch also doch in NAT-Thema. Vielleicht sind NATs doch nicht so gut ;)

Comments are closed.