Community Navigation
abbrechen
Vorschläge aktivieren
Mit der automatischen Vorschlagsfunktion können Sie Ihre Suchergebnisse eingrenzen, da während der Eingabe mögliche Treffer angezeigt werden.
Suchergebnisse werden angezeigt für 
Stattdessen suchen nach 
Meintest du 
1

Frage

2

Antwort

3

Lösung

SIP-Telefonie mit eigenen Geräten: Mit DS-Lite möglich? Firewall-Einstellungen
Gehe zu Lösung
helios17
Netzwerkforscher
Netzwerkforscher

am ‎01.09.2022 12:16

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).

0 Gefällt mir
12 Antworten 12
Gehe zu Lösung
Oberaffe
Smart-Analyzer
Smart-Analyzer
Als Antwort auf RobertP

am ‎01.09.2022 16:58

HI

 

wie schon oben erwähnt mit ip6 kein Problem

man könnte sich für ip4 statische Routen vorstellen muss das mal probieren

 

lg

0 Gefällt mir
Gehe zu Lösung
helios17
Netzwerkforscher
Netzwerkforscher
Als Antwort auf RobertP

am ‎01.09.2022 17:11

@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!

0 Gefällt mir
Gehe zu Lösung
helios17
Netzwerkforscher
Netzwerkforscher
Als Antwort auf helios17

am ‎01.09.2022 17:16

Achja, die richtige Präfix-Länge bekommt der Router automatisch.

0 Gefällt mir