Gelöst: Betreff: SIP-Telefonie mit eigenen Geräten: Mit DS...

helios17 · ‎01.09.2022

Hallo. Das ist mein erstes Post. Ich hoffe, ich habe die richtige Kategorie erwischt. Falls nicht bitte verschieben. Ich habe eigene Geräte und ich weiß, dafür gibt es keinen offiziellen Support. Vielleicht findet sich dennoch jemand, der sieht, was hier noch fehlt, damit es funktioniert.

Ich habe seit kurzem Vodafone Cable Max 1000 in Bayern, den ich Fritzbox-frei mit eigenen Geräten betreiben möchte.

Was bereits funktioniert:

- Kabelmodem Technicolor TC-4400 (Neugerät mit Firmware SR70.12.44)

- Internet via Omnia Turris (OpenWRT basiert): Der ist DHCP-Client vom Kabelmodem. Er bekommt eine öffentliche IPv4-Adresse. Es kommt auf dem Router jedoch offenbar DS-Lite zum Einsatz.

- Twinkle Softphone unter Linux sowie ein IP-Telefon insofern ich es an den zweiten Ethernet-Port vom Kabel-Modem anschließe. Die bekommen in diesem Fall auch eine öffentliche IP-Adresse, was ich nur zum Testen ausprobiert habe.

Was nicht funktioniert:

- Twinkle Softphone oder das IP-Telefon in meinem lokalen LAN, also hinter dem Omnia Turris. Das Twinkle lauscht bei einem Anruf neben Port 5060 auch auf Port 8000 und 8001.

Ich bekomme in Twinkle:

Vodafone, Anmeldung erfolglos: 408 Request Timeout


Leitung 1: Ruf erfolglos.

408 Request Timeout

Das möchte ich natürlich ändern, damit Twinkle bzw. dann das IP-Telefon im lokalen Netz funktionieren und daher vor Angriffen aus dem Internet durch den Router geschützt sind.

Was ich bisher versucht habe ist:

Traffic-Regeln für SIP (Port 5060) sowie RTP/RTCP (Port 8000-8009) an die Ziel-Adressen mein Router, mein Laptop, sowie dem IP-Telefon
Port-Weiterleitungen für SIP (Port 5060) sowie RTP/RTCP (Port 8000-8009). Zum Testen zunächst an mein Laptop, wo Twinkle läuft

Angepasste Einstellungen für das Twinkle Softphone sind - die beim direkten Anschluss an das Kabelmodem ja auch funktionieren:

Anmeldename: Meine Kundennummer
Passwort: Das generierte SIP-Passwort
Domain: sip.kabelfon.vodafone.de
Nutzername: Meine temporäre Telefonnummer vor der Rufnummernübernahme
SIP-Server - Registrar: sip.kabelfon.vodafone.de
Outbound-Proxy verwenden: sip.kabelfon.vodafone.de

Nun bin ich auf der Suche, wo noch der Fehler liegt. Dazu fehlen mir bereits die exakten Voraussetzungen, da ich widersprüchliche Informationen fand und einige Informationen gar nicht.

Meine derzeitige Einschätzung nach eigehender Recherche für einen Vodafone Kabel-Anschluss in Bayern war: Das dürfte sowohl über DS-Lite funktionieren und an sich sollte auch keine Port-Weiterleitung erforderlich sein, insofern der Outbound Proxy zum Einsatz kommt. Die in der Firewall zu erlaubenden Ports wären 5060 für SIP und 8000-8009 für RTP/RTCP. Ohne Port-Weiterleitung funktioniert es jedoch ebenso wenig wie mit. Inwiefern das wirklich mit DS-Lite geht ist mir auch nicht ganz klar. Immerhin kommt für sip.kabelfon.vodafone.de ja nur eine IPv4-Adresse zurück.

Ich sehe auf dem Omnia Turris:

24: br-wan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether […] brd ff:ff:ff:ff:ff:ff
    inet 188.194.[…]/24 brd 188.194.108.255 scope global br-wan
       valid_lft forever preferred_lft forever
    inet6 2a02:810d:[…]/128 scope global dynamic noprefixroute 
       valid_lft 5086sec preferred_lft 2386sec
    inet6 fe80::[…]/64 scope link 
       valid_lft forever preferred_lft forever
    RX: bytes  packets  errors  dropped overrun mcast   
    387599211  2199664  0       0       0       781     
    TX: bytes  packets  errors  dropped carrier collsns 
    37341908   147732   0       0       0       0       
25: ds-wan6_4@br-wan: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1280 qdisc noqueue state UNKNOWN group default qlen 1000
    link/tunnel6 2a02:810d:[…] peer 2a02:8100:[…]
    inet 192.0.0.2 peer 192.0.0.1/32 brd 255.255.255.255 scope global ds-wan6_4
       valid_lft forever preferred_lft forever
    inet6 fe80::e033:[…]/64 scope link 
       valid_lft forever preferred_lft forever
    RX: bytes  packets  errors  dropped overrun mcast   
    260367990  75426    0       0       0       0       
    TX: bytes  packets  errors  dropped carrier collsns 
    10615793   110965   1       1       1       0

Das sieht für mich nach einen doppelten NAT aus, was für SIP-Telefonie ja Probleme machen könnte.

Im Paketfilter sehe ich den VoIP-Traffic durchaus. Filter-Tabelle:

Chain zone_wan_forward (2 references)
 pkts bytes target     prot opt in     out     source               destination         
    4  1436 forwarding_wan_rule  all  --  *      *       0.0.0.0/0            0.0.0.0/0            /* !fw3: Custom wan forwarding rule chain */
    0     0 zone_lan_dest_ACCEPT  esp  --  *      *       0.0.0.0/0            0.0.0.0/0            /* !fw3: @rule[7] */
    0     0 zone_lan_dest_ACCEPT  udp  --  *      *       0.0.0.0/0            0.0.0.0/0            udp dpt:500 /* !fw3: @rule[8] */
    0     0 zone_lan_dest_ACCEPT  tcp  --  *      *       0.0.0.0/0            router             tcp dpt:5060 /* !fw3: SIP */
    0     0 zone_lan_dest_ACCEPT  tcp  --  *      *       0.0.0.0/0            laptop            tcp dpt:5060 /* !fw3: SIP */
    0     0 zone_lan_dest_ACCEPT  tcp  --  *      *       0.0.0.0/0            iptelefon           tcp dpt:5060 /* !fw3: SIP */
    0     0 zone_lan_dest_ACCEPT  udp  --  *      *       0.0.0.0/0            10.0.0.4             udp dpt:5060 /* !fw3: SIP */
    3  1392 zone_lan_dest_ACCEPT  udp  --  *      *       0.0.0.0/0            laptop            udp dpt:5060 /* !fw3: SIP */
    0     0 zone_lan_dest_ACCEPT  udp  --  *      *       0.0.0.0/0            iptelefon           udp dpt:5060 /* !fw3: SIP */
    0     0 zone_lan_dest_ACCEPT  tcp  --  *      *       0.0.0.0/0            10.0.0.4             tcp dpts:8000:8009 /* !fw3: RTP und RTCP */
    1    44 zone_lan_dest_ACCEPT  tcp  --  *      *       0.0.0.0/0            laptop            tcp dpts:8000:8009 /* !fw3: RTP und RTCP */

NAT-WAN-Prerouting-Tabelle:

Chain zone_wan_prerouting (2 references)
 pkts bytes target     prot opt in     out     source               destination         
  335 16842 prerouting_wan_rule  all  --  *      *       0.0.0.0/0            0.0.0.0/0            /* !fw3: Custom wan prerouting rule chain */
    0     0 DNAT       tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:5060 /* !fw3: SIP */ to:laptop:5060
    3  1392 DNAT       udp  --  *      *       0.0.0.0/0            0.0.0.0/0            udp dpt:5060 /* !fw3: SIP */ to:laptop:5060
    1    44 DNAT       tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpts:8000:8009 /* !fw3: RTP/RTCP */ to:laptop:8000-8009
    0     0 DNAT       udp  --  *      *       0.0.0.0/0            0.0.0.0/0            udp dpts:8000:8009 /* !fw3: RTP/RTCP */ to:laptop:8000-8009

Allerdings taucht der Traffic dann nicht in der LAN-Prerouting-Tabelle auf und zwar weder für die Public IP, die der Omnia Turris vom Kabelmodem gezogen hat, noch für DS-Lite:

Chain zone_lan_prerouting (1 references)
 pkts bytes target     prot opt in     out     source               destination         
  597 39386 prerouting_lan_rule  all  --  *      *       0.0.0.0/0            0.0.0.0/0            /* !fw3: Custom lan prerouting rule chain */
    0     0 DNAT       tcp  --  *      *       10.0.0.0/16          188.194.br-wan      tcp dpt:5060 /* !fw3: SIP (reflection) */ to:laptop:5060
    0     0 DNAT       udp  --  *      *       10.0.0.0/16          188.194.br-wan      udp dpt:5060 /* !fw3: SIP (reflection) */ to:laptop:5060
    0     0 DNAT       tcp  --  *      *       10.0.0.0/16          192.0.0.2            tcp dpt:5060 /* !fw3: SIP (reflection) */ to:laptop:5060
    0     0 DNAT       udp  --  *      *       10.0.0.0/16          192.0.0.2            udp dpt:5060 /* !fw3: SIP (reflection) */ to:laptop:5060
    0     0 DNAT       tcp  --  *      *       10.0.0.0/16          188.194.br-wan      tcp dpts:8000:8009 /* !fw3: RTP/RTCP (reflection) */ to:laptop:8000-8009
    0     0 DNAT       udp  --  *      *       10.0.0.0/16          188.194.br-wan      udp dpts:8000:8009 /* !fw3: RTP/RTCP (reflection) */ to:laptop:8000-8009
    0     0 DNAT       tcp  --  *      *       10.0.0.0/16          192.0.0.2            tcp dpts:8000:8009 /* !fw3: RTP/RTCP (reflection) */ to:laptop:8000-8009
    0     0 DNAT       udp  --  *      *       10.0.0.0/16          192.0.0.2            udp dpts:8000:8009 /* !fw3: RTP/RTCP (reflection) */ to:laptop:8000-8009

Irgendwelche Ideen?

Gibt es irgendwo eine exakte und aktuelle Zusammenfassung für die Voraussetzungen für selbst gemachte SIP-Telefonie mit Einstellungen, Paket-Filter-Regeln, DNAT ja/nein?, DS-Lite ja/nein? usw. Oder gibt es gar irgendwo ein Beispiel für OpenWRT mit dem Vodafone Kabel-Anschluss?

Mittel- bis langfristig plane ich eine eigene Asterisk basierte Telefonanlage einzurichten – zumindest dann wenn ich den Anrufbeantworter über das IP-Telefon (lokal) nicht hinbekomme. Möglicherweise mit dem Aufsatz FreedomPBX. Aber dafür müssen ja zunächst mal die Grundlagen funktionieren. Idealerweise bis Sonntag, da ich bis dahin noch kostenlos mit dem alten ISDN-Festnetz-Anschluss testen kann, den ich nur sehr ungern hergebe (damals als Telefonie mit eigenen Endgeräten noch einfach war).

helios17 · ‎01.09.2022

@RobertP schrieb:
in Bayern hast du mit einem TC4400 und eigenem Router definitiv einen "echten" Dual Stack
hier auch gut zu sehen:
Protokoll: DHCPv6 Client
[…]
IPv6: 2a02:810d:8000:[…]/128
IPv6 Präfix-Delegation (PD): 2a02:810d:[…]/56
das Problem muss also mit deinem Router zusammenhängen, oder OpenWRT fehl da noch irgendein Paket

Ok, endlich habe ich es. Es war kein Paket zu wenig. Es war eines zu viel. Sobald das Paket "ds-lite" installiert ist, macht das OpenWrt auf dem Omnia Turris eben Dual Stack Lite. Entferne ich dieses Paket und lasse dann auf der Netzwerk-Schnittstelle, wo das Kabelmodem dran hängt, einmal einen DHCP-Client und einmal einen DHCPv6-Client laufen, dann funktioniert das.

Vielen Dank für eure Geduld und Unterstützung!

Lösung in ursprünglichem Beitrag anzeigen

reneromann · ‎01.09.2022

Verwendest du den DNS von Vodafone?

Außerdem hast du kein DS-Lite im Einsatz, sondern DualStack...

helios17 · ‎01.09.2022

Also ich hab eine Lösung gefunden. Die zerbröselt mir jedoch IPv6. Da mein Router vom Kabelmodem ja eine öffentliche IPv4-Adresse bekommt, habe ich jetzt mal versucht DS-Lite auf dem Omnia Turris zu deaktiveren.

Ich habe jetzt also nur noch eine WAN-Schnittstelle, die DHCP-Client (IPv4) für das Kabelmodem spielt.

So klappt es auf Anhieb. Weder brauche ich Traffic-Regeln für eingehenden SIP/RTP/RTCP-Datenverkehr noch irgendwelche Port-Weiterleitungen. Ich habe diese Regeln nun alle ausgeschaltet und via Twinkle funktioniert die Telefonie einfach.

Sobald ich jedoch erneut eine WAN6-Schnittstelle als DHCPv6-Client auf das Kabelmodem hinzufüge, aktiviert OpenWRT auch eine Schnittstelle für einen DSLite-Tunnel. Und dann geht es nicht mehr.

Ich hoffe, es gelingt mir über die Hotline DS-Lite für meinen Anschluss abschalten zu lassen. Bis dahin gibt es erst mal nur IPv4 als Work-Around.

helios17 · ‎01.09.2022

Okay, ja. Es ist Dual Stack, kein DS-Lite. Ich hab mich von dem kürzeren Schnittstellen-Namen mit "ds" in die Irre führen lassen. In der OpenWrt-Web-Oberfläche ist es eindeutig: "Virtuelle dynamische Schnittstelle (Dual-Stack Lite (RFC6333)". Damit dürfte sich der Anruf bei der Support-Hotline, um DSLite abschalten zu lassen ja erübrigen. Danke für den Hinweis!

Okay, dann funktioniert es derzeit nicht mit Dual Stack. Warum auch immer.

DNS läuft beim Omnia Turris über einen eigenen Resolver. Der löst sip.kabelfon.vodafone.de auf die IP-Adresse 88.134.209.241 auf. Eine IPv6-Adresse kommt da nicht als Antwort. Die WAN-Schnittstelle nutzt als DHCP-Client die DNS-Server, die das Kabelmodem bereit stellt. Ich vermute mal, das nimmt der Knot Resolver dann als Upstream-DNS. Ganz sicher bin ich mir dessen jedoch nicht.

RobertP · ‎01.09.2022

@helios17 schrieb:
- Twinkle Softphone unter Linux sowie ein IP-Telefon insofern ich es an den zweiten Ethernet-Port vom Kabel-Modem anschließe.

das kann so eigentlich nicht richtig funktionieren, am TC4400 kann nur ein Ethernet Port für den eigenen Router verwendet werden und der bekommt dann die eine öffentliche IP, aber das möchtest du ja eigentlich auch gar nicht so betreiben 😉

zurück zu deinem Problem:

ich vermute, dass deine Firewall Einstellungen noch unvollständig sind

für RTP habe ich die Ports 7078-7109 erlaubt und 5060 für SIP

hier noch ein Beispiel Fritzbox hinter pfSense, vielleicht hilft es dir ja

helios17 · ‎01.09.2022

Oh, das hat sehr wohl funktioniert mit dem IP-Telefon oder Laptop am zweiten Ethernet-Port vom Kabelmodem. Twinkle nutzte dort die Ports 5060, 8000 und 8001, die ich ja auch im Omnia Turris freigeschaltet hatte. Ich bekomme auf beiden Ethernet-Schnittstellen des Kabelmodems eine IPv4-Adresse. Auch die Firewall-Regeln sind nicht erforderlich, zumindest im einfachen Fall, dass ich auf dem Router nur IPv4 verwende. Es geht exakt dann nicht mehr, wenn ich versuche IPv6 an den Start zu bringen. Das funktioniert dann zwar, aber dann klappt die IP-Telefonie nicht mehr. Warum weiß ich noch nicht. Workaround ist im Moment, nur IPv4 zu nutzen, bis ich eine Lösung habe.

helios17 · ‎01.09.2022

Okay, das VoIP-Telefon funktioniert nur mit IPv4 auf dem Router ebenfalls. Das Grund-Problem ist also an sich erst mal gelöst.

Nur hätte ich das gerne jetzt auch noch mit IPv6 für den Internet-Zugriff. Da werde ich dann mal recherchieren, wie das mit OpenWrt in Kombination mit einem Vodafone Kabel-Anschluss am besten funktioniert. Wer bereits einen Link dazu hat oder das selbst im Einsatz hat, bitte gerne einen noch einen Hinweis geben. Vielen Dank.

RobertP · ‎01.09.2022

hast du die richtige Präfixgröße angefordert?

in Bayern 56

Nachtrag:

deine Vodafone Nummern funktionieren übrigens ausschließlich über IPv4, da der Registrar "sip.kabelfon.vodafone.de" nur per IPv4 ereichbar ist

wie sich das bei Twinkle verhält kann ich dir nicht sagen

helios17 · ‎01.09.2022

@RobertP schrieb:
hast du die richtige Präfixgröße angefordert?
in Bayern 56

Nachtrag:
deine Vodafone Nummern funktionieren übrigens ausschließlich über IPv4, da der Registrar "sip.kabelfon.vodafone.de" nur per IPv4 ereichbar ist
wie sich das bei Twinkle verhält kann ich dir nicht sagen

Also das mit der Präfix-Länge hatte ich gar nicht beachtet. Aber nun habe ich es noch mal probiert, und 56 als Präfix-Länge angerfordert. Das ergibt:

Protokoll: DHCPv6 Client
Laufzeit: 0h 2m 30s
MAC: […]
RX: 143.62 MB (1999760 Pkte.)
TX: 8.62 MB (51044 Pkte.)
IPv6: 2a02:810d:8000:[…]/128
IPv6 Präfix-Delegation (PD): 2a02:810d:[…]/56

Ich bekomme dann gleich wieder so eine "Virtuelle dynamische Schnittstelle (Dual-Stack Lite (RFC6333))" dazu von OpenWrt. Mit dem gleichen Ergebnis wie zuvor: IP-Telefonie funktioniert dann nicht mehr. Weder mit Twinkle noch mit dem IP-Telefon.

Und ich hab das jetzt nochmal überprüft: RFC 6333 ist, wenn ich das richtig sehe Dual Stack Lite. Siehe: https://www.rfc-editor.org/rfc/rfc6333.txt

Also verwendet der Router doch Dual Stack Lite im Falle dessen, dass ich IPv6 verwende? Im Grunde sagt es ja die Bezeichnung der Schnittstelle bereits. Ich habe mich da jetzt doch durch die Antwort von @reneromann verwirren lassen. dslite dürfte doch eine Abkürzung für Dual Stack Lite sein, oder nicht? Ja, laut meiner Recherche. Ich denke, ich rufe doch mal bei der Hotline an, anstatt herum zu raten, was für meinen Anschluss eingestellt ist.

RobertP · ‎01.09.2022

in Bayern hast du mit einem TC4400 und eigenem Router definitiv einen "echten" Dual Stack

hier auch gut zu sehen:

Protokoll: DHCPv6 Client
Laufzeit: 0h 2m 30s
MAC: […]
RX: 143.62 MB (1999760 Pkte.)
TX: 8.62 MB (51044 Pkte.)
IPv6: 2a02:810d:8000:[…]/128
IPv6 Präfix-Delegation (PD): 2a02:810d:[…]/56

das Problem muss also mit deinem Router zusammenhängen, oder OpenWRT fehl da noch irgendein Paket