Unitymedia UM SIP - Eingehende Anrufe nur mit offenen Port 5060

[Nurum]

Hallo,

ich habe ein kleines Problem mit meinem VOIP Setup. TC4400 (Modem) + Edgerouter X (Router) + Fritzbox 7362SL (Telefonanlage).
Die Telefonie läuft in meinem Fall bevorzugt über IPv6. Nach einem Neustart der Fritzbox funktionieren eingehende Anrufe eine Weile, dann aber nicht mehr. Deshalb habe ich für die IPv6 Adresse der Fritzbox eine Ausnahmeregel in der Firewall des Edgerouters erstellt, die Port 5060 zur Fritzbox durchlässt. So funktioniert die Telefonie dauerhaft.

Ich habe hier öfters gelesen, dass es unratsam ist Port 5060 offen zu lassen. Gibt es eine elegantere Lösung das Problem ohne geöffnete Firewall zu lösen?

 

[rv112]

Es ist definitiv unratsam den Port zu öffnen. Hier laufen fast im Minutentakt Angriffe auf den Port. Du musst entweder im VOIP Gateway (in Deinem Fall die Fritte) oder in Deiner Firewall NAT Keepalive setzen. Eventuell auch Static Port für den Client (Fritte).

 

[addicted]

IPv6... NAT Keepalive ...
Bevor jetzt jemand verwirrt ist, da geht's um Connection Tracking, das ist für Protokolle wie SIP und FTP notwendig, damit man "related" Pakete auf anderen Ports einer bereits aufgebauten Verbindung zuordnen kann. Funktioniert übrigens grandios nicht mehr, wenn man Verschlüsselung hat
Ich würde beides machen: Auf dem Router entsprechende Einstellungen für CT setzen oder erweitern und auf dem SIP-Client alle Keepalive-Funktionen aktivieren.

Wenn das übrigens alles nichts bringt, dann mach eine Regel, die Verbindungen zu 5060 nicht von überall, sondern nur von den SIP-Gateways bei UM durchlässt. Wenn Du die Regel breit genug machst (entsprechende Netze bei UM), dann können sich einzelne IPs auch mal ändern, ohne dass Du nochmal dran musst.

 

[THX1138]

Ich habe hier öfters gelesen, dass es unratsam ist Port 5060 offen zu lassen. Gibt es eine elegantere Lösung das Problem ohne geöffnete Firewall zu lösen?

Ich habe eine ähnliche Konfiguration (TC4400 - Asus Merlin-WRT - FB 7390 für VoIP). Im Gegensatz zu IPv4, wo die FB ein Keepalive macht, um das NAT-Mapping aufrecht zu erhalten, macht sie das bei IPv6 leider nicht.

Ich habe deshalb auch im Firewall Inbound-SIP auf die FB geöffnet. Aber mit Sourcefiltering. D.h. nur Pakete von (in meinem Fall) "2a02:0908:000a:1000::/64" kommen bei mir durch die Firewall.

Falls Dein Firewall Sourcefiltering unterstützt, must Du nur einmal schauen, was die Adresse des Dir zugewiesenen SIP-Servers ist und kannst dann den Traffic auf diesen Server oder das Netzwerk beschränken.

 

[rv112]

Sorry, IPv6 habe ich überlesen. Ich nutze für Telefonie ausschließlich IPv4.

 

[Nurum]

Danke für die Anregungen. Ich habe nun sicherheitshalber in der Firewall die Source IPv6 meines Registrars bei UM eingetragen.
Ich hatte in meinem Router die Einstellung "system conntrack modules sip" deaktiviert. Ich werde mal testen, ob ich die Firewall Regel noch brauche, wenn ich sie wieder aktivere.
"Portweiterleitung aktiv halten" habe ich in der Fritzbox von 5min auf 30sek gesetzt. Schätze das sollte aber nicht ändern.

Hatte vergessen, dass ich an dieser Einstellung rumgespielt habe, als ich andere Probleme mit SIP hatte. Wenn das das der Fehler war, dann habe ich zumindest für die Zukunft gelernt: "Nicht an Einstellungen drehen, wenn man keine Ahnung hat"

 

[rv112]

Portweiterleitung aktiv halten könnte eventuell schon etwas bringen. Je nachdem wie Deine Firewall eingestellt ist schließt sie schon vor 5 Minuten offene Verbindungen.

 

[Nurum]

Habe es jetzt nochmals getestet. Mit "system conntrack modules sip" im Router und(/oder) mit "Portweiterleitung aktiv halten" alle 30sek in der Fritzbox scheint es auch ohne manuell geöffneten Port zu gehen.
Da im Ubiquiti-Forum der Option "system conntrack modules sip" nachgesagt wird, Probleme mit SIP verursachen zu können, were ich falls ich die Probleme auftreten sollten wieder auf die Firewall Regel mit entsprechender Souce- und Destination IP umsteigen.

Nochmal danke für die Hilfe. Allein wäre ich da nicht drauf gekommen.

 

[Nopileus]

Ich habe das SIP conntrack modul deaktiviert benutze aber upnp2, dies muss man manuell aktivieren. (nicht über den wizard)

Geöffnet habe ich sonst nichts.

 

[sch4kal]

Ich habe das SIP conntrack modul deaktiviert benutze aber upnp2, dies muss man manuell aktivieren. (nicht über den wizard)

Geöffnet habe ich sonst nichts.

Was nichts anderes tun dürfte als die entsprechenden Ports in der Firewall zu öffnen.
UPnP ist ein einziges Sicherheitsrisiko, wenn sogar schon das BSI davor warnt, besser sofort und ganz abschalten.

 

[addicted]

UPnP selbst ist überhaupt kein Sicherheitsrisiko.
Hat man allerdings schon Schadsoftware in seinem Netzwerk, oder eine Software (z.B. Browser) lässt sich durch eine Sicherheitslücke dazu bringen, beliebige Requests ins interne Netzwerk zu senden, dann kann das mit UPnP ggf. mehr Schaden anrichten als ohne.
Die Verschlimmerung besteht darin, dass bösartige Software ebenfalls Ports für eingehende Verbindungen öffnen kann und dadurch nicht nur auf ausgehende Verbindungen angewiesen ist, die in der Regel immer erlaubt sind.

 

[Nurum]

Ich habe das SIP conntrack modul deaktiviert benutze aber upnp2, dies muss man manuell aktivieren. (nicht über den wizard)

Geöffnet habe ich sonst nichts.

Ich habe auch testweise upnp2 aktiviert. Die Fritzbox fordert aber keine Öffnung der Ports an. Kann sein, dass sie das für IPv6 nicht tut. Bin mir nicht mal sicher ob die von Ubiquiti implementierte Variante von miniupnpd (upnp2) überhaupt IPv6 unterstützt. Müsste das mal testen.
Wird dir überhaupt einen Eintrag für die Fritzbox angezeigt, wenn du per "show upnp2 rules" die Portfreigaben abfragst?

Ja, ich weiß auch, dass UPnP ein Sicherheitsrisiko sein kann. Werde es in Zukunft nur mit einer Whitelist nutzen.

Edit: Da es einen Feature Request für IPv6 UPnP gibt, gehe ich mal davon aus, dass UPnP auf den Edgeroutern noch nicht mit IPv6 zurechtkommt. https://community.ubnt.com/t5/UniFi-Routing-Switching-Feature/UPnP-IPv6-support/idi-p/2157325

 

[Nopileus]

Bei mir läuft noch alles über ipv4, Fritzbox fordert definitiv die ports an und bekommt sie auch.

Schade dass v6 noch so halbgar ist.

 

[why_]

Das hat nichts mit IPv6 zu tun sondern mit der Unfähigkeit von bestimmten Firmen. Bei mir funktioniert es via V6 problemlos mit OpenWRT und Phoner hier.

 

[Nopileus]

War auch auf ubiquiti bezogen.

 

[Nurum]

Ubiquiti muss beim IPv6 Support noch etwas nachbessern. Bin da schon öfter auf Limitierungen gestoßen, die bei beispielsweise OpenWRT gelöst sind.
Bin da wahrscheinlich ein bisschen zu ambitioniert, da ich recht zwanghaft versuche möglichst viel über IPv6 zu lösen.

 

[boba]

Bin da wahrscheinlich ein bisschen zu ambitioniert, da ich recht zwanghaft versuche möglichst viel über IPv6 zu lösen.

Habe ich auch versucht, bin bei vielen kleinen Details immer wieder gescheitert. Seitdem läuft ipv6 einfach nur noch so mit. Die Adressvergabe geht ja vollautomatisch, ausgehende ipv6 Verbindungen funktionieren einfach ohne dass man was tun müsste, und die ipv6 Firewalls der einzelnen Maschinen sind standardmäßig zu. Passt also.

Der Rest, also Serverdienste und Anwendungen, wird deshalb nur via ipv4 gemacht. Wenn neue Generationen von Router, Serverdiensten und Linuxdistributionen rauskommen, also alle paar Jahre mal, dann schaue ich, ob man vielleicht mehr mit ipv6 tun könnte. Bislang war das allerdings nicht der Fall. Die Details, an denen es hapert, sind immer noch vorhanden. Es ist nicht das Protokoll selbst, sondern es sind die Management-Sachen, die noch nicht gut genug funktionieren. Größter (aber nicht einziger) Knackpunkt bisher war immer der prefix-Wechsel.

 

[why_]

Woran scheitert es denn bei euch beim Prefix wechsel?
Ich fahre jetzt seit ein paar Jahren alles über IPv6 und konnte eigentlich nur bei SMTP Einschränkungen feststellen.

 

[nts]

Bei dem ER-X funktioniert IPv6 noch nicht einmal solange hwnat aktiviert ist. Wenn Ubiquiti da nicht nachbessert, bin ich nach dem nächsten Tarifupgrade wieder mit IPv4-only unterwegs :zunge:

 

[boba]

Probleme beim Prefix-Wechsel: Manch ein Serverdienst muss bei Prefixwechsel neu gestartet werden. Bei ipv4 fällt das nicht auf, interne Adressen bleiben ja immer gleich. Dann braucht manch ein Serverdienst eine an den Prefix angepasste Konfiguration. Deren Konfiguration müsste den neuen Prefix in die Configdatei generiert bekommen. Es gibt kein Event, keinen hook, der bei Prefix-Wechsel ausgelöst wird, bei dem man ein Skript ausführen könnte. Ich habe zumindest keinen gefunden. Damit klappt auch eine dynamische DNS-Registrierung von ipv6 Adressen an einem lokalen DNS Server bei prefix-Wechsel nicht.
Und dann wären da noch Firewalls und ip-basierte Zugriffsregeln, die bei prefix-Wechsel umkonfiguriert werden müssen. Da ist noch soviel Gefrickel dabei.

 

[THX1138]

Und dann wären da noch Firewalls und ip-basierte Zugriffsregeln, die bei prefix-Wechsel umkonfiguriert werden müssen. Da ist noch soviel Gefrickel dabei.

Zu mindestens das kann man sich bei ip6tables durch Maskierung erleichtern. Für inbound SIP habe ich z.B.

ip6tables -I FORWARD 8 -i eth0 -o br0 -p udp -m udp -s 2001:DB8::1 -d ::xxxx:xxff:fexx:xxxx/::ffff:ffff:ffff:ffff --sport 5060 --dport 5060 -m state --state NEW -j ACCEPT

Damit wird nur der Hostpart der Serveradresse benutzt. Dadurch sind Prefixwechsel unkritisch.

Etwas unschön ist in der Tat das Thema DDNS. Das habe ich mit einem Powershellskript auf dem Server gelöst, das alle 15Min läuft. Nicht toll, aber für meine Zwecke akzeptabel.

Und für internen Verkehr benutze ich einen statischen ULA-Prefix (RFC4193), der in den PrefixPolicies eine höhere Priorität als der globale IPv6-Prefix und IPv4 hat. Das ist dann wie bei einem privaten IPv4 Netz (RFC1918).

 

[why_]

Probleme beim Prefix-Wechsel: Manch ein Serverdienst muss bei Prefixwechsel neu gestartet werden. Bei ipv4 fällt das nicht auf, interne Adressen bleiben ja immer gleich. Dann braucht manch ein Serverdienst eine an den Prefix angepasste Konfiguration. Deren Konfiguration müsste den neuen Prefix in die Configdatei generiert bekommen. Es gibt kein Event, keinen hook, der bei Prefix-Wechsel ausgelöst wird, bei dem man ein Skript ausführen könnte. Ich habe zumindest keinen gefunden.

Statt auf eine Spezifische kannst du dich doch an [::] binden, dann ist ein prefix wechsel egal

Damit klappt auch eine dynamische DNS-Registrierung von ipv6 Adressen an einem lokalen DNS Server bei prefix-Wechsel nicht.

Mit ddclient hatte ich da noch nie Probleme das die IP nicht geupdatet wurde, und den nutze ich an einem Telekom anschluss, da wechselt das Prefix mehrmals im Monat.

Und dann wären da noch Firewalls und ip-basierte Zugriffsregeln, die bei prefix-Wechsel umkonfiguriert werden müssen. Da ist noch soviel Gefrickel dabei.

THX1138 hat ja schon die Lösung dazu gepostet, das funktioniert wunderbar mit OpenWRT für die Firewall rules.
Allerdings nutze ich Link Lokal adressen statt ULA, da die immer gleich sind, selbst wenn kein Router im Netzwerk vorhanden ist.

 

[THX1138]

Allerdings nutze ich Link Lokal adressen statt ULA, da die immer gleich sind, selbst wenn kein Router im Netzwerk vorhanden ist.

Da ich eine Windows ActiveDirectory Domain zu Hause fahre, die auch einen DNS-Server mit dynamischen Updates beinhaltet (RFC 2136), verwende ich im Prinzip nur Hostnamen und keine IP(v6)-Adressen. Die ULA-Adressen werden ohne Probleme dort dynamisch registriert. Link-Lokal-Adressen nicht. Ich weiss noch nicht einmal, ob man Link-Lokal-Adressen in den DNS-Server reinbekommt, da ja bei LL-Adressen auch der Zonen-Index immer noch eine Rolle spielt.

 

[why_]

Allerdings nutze ich Link Lokal adressen statt ULA, da die immer gleich sind, selbst wenn kein Router im Netzwerk vorhanden ist.

Da ich eine Windows ActiveDirectory Domain zu Hause fahre, die auch einen DNS-Server mit dynamischen Updates beinhaltet (RFC 2136), verwende ich im Prinzip nur Hostnamen und keine IP(v6)-Adressen. Die ULA-Adressen werden ohne Probleme dort dynamisch registriert. Link-Lokal-Adressen nicht. Ich weiss noch nicht einmal, ob man Link-Lokal-Adressen in den DNS-Server reinbekommt, da ja bei LL-Adressen auch der Zonen-Index immer noch eine Rolle spielt.

Ich hab hier nur Linux für Server im Einsatz und einen Windows Client, deswegen habe ich keine Ahnung was ein AD mit LL-Adressen macht, da für mich völlig irrelevant, aber zumindest Android, Windows und Linux haben kein Problem damit LL Adressen als DNS zu nehmen wenn sie die per DHCP bzw. im Fall von Android per neighbour discovery bekommen.

 

[boba]

Bei ULA oder LL Adressen gibt es das Problem, dass wenn ich Maschinen habe, die alle ihre ipv6 Adressen im dns registriert haben, die Verbindung zu der öffentlichen ipv6 Adresse aufgebaut wurde, selbst wenn es sich um eine Maschine im LAN handelt. Da die öffentlichen ipv6 Adressen meines LANs jedoch nicht in deren Firewall freigeschaltet sind, kann damit keine Verbindung aufgebaut werden. Wären sie in der Firewall freigeschaltet, dann ginge das, aber dazu müsste bei prefix-Wechsel ein Skript laufen können, das die Firewall bei allen Kisten im LAN umkonfiguriert.
Wenn ich wiederum nur die ULA oder LL Adressen im dns registriere, dann gabs irgendwelche anderen Dinge, die problematisch waren. Nagelt mich nicht darauf fest was das genau war, irgendwas war da.

Apropos dhcpv6. Das einzusetzen würde bedeuten, der dhcpv6 Server würde den prefix-Wechsel erkennen und sich entsprechend umkonfigurieren können. Das wiederum kann nicht jeder, und die, die es können, sind entweder nicht in der Distribution drin (Centos 7) oder denen fehlen Features oder Konfigurations-Strukturen, die ich haben will oder brauche. Da war z.B. irgendwas, das dem Einsatz von dnsmasq im Weg stand.

Ich schrieb schon: das ist das totale Gefrickel. Ich warte da lieber ein paar weitere Jahre und schaue mal, was sich da als "best practice" entwickelt.