Probleme bei VoIP Konfiguration - USG Pro + Grandstream DP752

[urzani]

Hallo zusammen !

Ich versuche folgendes ans Laufen zu bringen ( es ging mal): Telekom LWL Anschluss ==> USG Pro ==> Grandstream DP752 ==>Grandstream DP730.
Bei der Basisstation DP752 habe ich die Anmeldedaten für den SIP-Server der Telekom eingerichtet und im USG Port forwarding für die Ports 5060 (SIP) und 50000 (RTP) eingetragen.
Das Handheld DP730 registriert sich ohne weiteres an der Basisstation, leider diese nicht am SIP der Telekom. Das ging allerdings vor einigen Monaten. Damals mit Spam-Anrufen um die 80 in der Minute. Daraufhin habe ich IDS für VOIP im USG aktiviert. Geht aber auch nicht wenn ich das deaktiviere.

Bin um jede Hilfe dankbar !

 

[frank_m24]

Sowohl den Thread Titel als auch den Ort für die Frage halte ich für misslungen. Aber bevor du jetzt einen Doppelpost erzeugst: Melde den Beitrag und bitte um Verschiebung. Im Thread-Titel sollte eine Kurzzusammenfassung des Problems stehen. Dann klappts auch mit der Hilfe.

 

[KunterBunter]

Das ging allerdings vor einigen Monaten.

Das passende Unterforum ist voll mit Beiträgen, dass jetzt bei der Telekom DNS SRV genutzt wird.

 

[stoney]

passend verschoben - Titel bitte selbst anpassen, danke.

 

[sonyKatze]

Drei Antworten ohne konkrete Hilfe zum Thema … kann man solch administrativen Hinweisen nicht über persönliche Nachrichten abwickeln oder wenigstens hinterher löschen?

Telekom LWL

Ideal(er) wäre der Namen Deines Tarifs. Ich vermute mit „LWL“ meinst Du einen Glasfaser-Anschluss. Das ist lediglich die phsikalische Übertragung. Telekom Deutschland fährt viele Tarife über Glasfaser, alle ein wenig anders, was die Konfiguration angeht.

IDS für VOIP im USG

Du hast in Deinem UniFi Security Gateway (USG), in dessen Firewall, das Intrusion Detection System (IDS) für Voice-over-IP (VoIP/SIP) aktiviert. Das ist in Deinem Aufbau nicht nötig, denn eine Grandstream DP75x baut eine Client-Verbindung zur Telekom Deutschland auf. Das ist eine eins-zu-eins Beziehung zwischen Dir und einer IP-Adresse bzw. Domain im Internet. Spam-Anrufe die über diese Beziehung hereinkommen, kannst Du lediglich auf der Ebene Telefenanschluss herausfiltern, siehe dazu die Anleitung moderner Telefonanschluss … (siehe Seite 26 und Seite 30; original Quelle)

im USG Port forwarding für die Ports 5060 (SIP) und 50000 (RTP) eingetragen

Das ist in Deinem Aufbau nicht nötig, denn eine Grandstream DP75x öffnet von sich aus die Ports in der Firewall. Außerdem enthält sie Strategien für ankommende und laufende Gespräche die Firewall (genauer das NAT-Bindung) aufrechtzuerhalten. Wenn das nicht von Haus aus in Deinem Fall klappt, müssen wir genau schauen, wie wir das konfigurieren … Port-Forwarding führt dazu, dass Deine Grandstream für alle IP-Adressen auf der Welt ansprechbar ist. Je nachdem wie die Grandstream konfiguriert ist, akzeptiert diese dann solche Anrufe, was dann zu Spam-Anrufen führt. Lange Rede, kurzer Sinn: Du hast Symptome mit den falschen Mitteln bekämpft†.

ging […] vor einigen Monaten

Wie KunterBunter schon andeutete, erfordert Telekom Deutschland inzwischen DNS-SRV. Das schaltest Du z. B. über

Grandstream → Web-Oberfläche → (Reiter) „Profile“ oder „Account“ → Network → DNS Mode: NAPTR​

ein. Wenn das nicht half, müssten wir über einen Paket-Mitschnitt der SIP-Nachrichten klären, was genau die Ursache ist. Weißt Du wie, Du so einen Mitschnitt erstellst? Wenn nicht, helfen wir gerne.

† Gerne helfe ich Dir dabei, denn ich habe hier ebenfalls Grandstream DP730/DP75x/DP760. Aber selbst damit kann ich das nur abstrakt machen, weil ich weder Deinen Telekom Tarif noch eine USG habe. Daher eine ganz andere Frage, aus reiner Neugierde: Warum hast Du Dich für Grandstream und nicht für eine Gigaset N510 IP Pro, Gigaset GO-Box 100 oder eine FRITZ!Box (im Modus IP-Client) entschieden? Jene drei DECT-Basen sind für den Einsatz mit der Telekom Deutschland getestet. Letztere bietet seit FRITZ!OS 07.2x mit der Telekom Deutschland sogar verschlüsselte Telefonie – mit einem einzigen zusätzlichen Anhaken in deren Web-Oberfläche. Auch kommen diese Geräte bereits von Haus aus so vorkonfiguriert, dass Du Dich nicht um Port-Forwardings oder Spam-Anrufe kümmern musst.

 

[urzani]

Es geht ! Und ganz ohne Spamanrufe! Vielen, vielen Dank !
War dann doch recht einfach:
- Hab alle Port Forwarding Einträge aus dem USG entfernt
- Ebenso IDS für VoIP
- An der DP752 NAPTR eingestellt.
Den Tarif musste ich erstmal nachsehen: MagentaZuhause XL.
Bin sehr happy. Nochmal vielen, vielen Dank !

 

[sonyKatze]

Du bist jetzt erfolgreich registiert. Aber ob Du durchgehend erreichbar bist, ist die nächste Frage. Dafür musst Du von Deiner USG das NAT-Bindung-Timeout ermitteln. Das kannst Du zum Beispiel so … die ermittelten Sekunden trägst Du ein unter

Grandstream → Web-Oberfläche → (Reiter) Network → Settings → Advanced: (STUN) Keep-Alive Interval​

Keep-Alive aktivierst Du unter

Grandstream → Web-Oberfläche → (Reiter) „Profile“ oder „Account“ → Network → (NAT) Traversal: Keep-Alive​

So bist Du durchgehend erreichbar, weil das Grandstream alle x Sekunden ein Double-CRLF sendet, und so das NAT-Binding re-fresh-ed.

Wenn das klappt, ist die nächste Frage, ob Du alle Gesprächsziele erreichst bzw. immer in beide Richtungen Audio hast. Und hier fängt Hören-Sagen an, weil ich persönlich kein Telekom Deutschland aber schon Stimmen gelesen habe: „Bei Telekom Deutschland muss immer die öffentliche IP-Adresse in den SIP- bzw- SDP-Nachrichten stehen“. Folglich müsstest Du mit einem Grandstream auch STUN aktivieren:

1. auf der globalen Network-Seite irgendeinen STUN-Server eintragen z.B. stun.t-online.de und
2. auf der Account-spezifischen Network-Seite statt Keep-Alive doch STUN auswählen.

 

[urzani]

Ok. Den STUN der Telekom hatte ich bereits eingetragen. Keep-Alive war auch bereits eingestellt. Das habe ich jetzt auf STUN umgestellt.
Aktuell sendet die Grandstream alle 20sek ein UDP blank an den SIP.
Ich habe folgende Werte vom USG auslesen können ( Befehl "sudo sysctl -a | grep conntrack | grep timeout" über shell)

net.netfilter.nf_conntrack_events_retry_timeout = 15
net.netfilter.nf_conntrack_frag6_timeout = 60
net.netfilter.nf_conntrack_generic_timeout = 600
net.netfilter.nf_conntrack_icmp_timeout = 30
net.netfilter.nf_conntrack_icmpv6_timeout = 30
net.netfilter.nf_conntrack_tcp_timeout_close = 10
net.netfilter.nf_conntrack_tcp_timeout_close_wait = 60
net.netfilter.nf_conntrack_tcp_timeout_established = 7440
net.netfilter.nf_conntrack_tcp_timeout_fin_wait = 120
net.netfilter.nf_conntrack_tcp_timeout_last_ack = 30
net.netfilter.nf_conntrack_tcp_timeout_max_retrans = 3600
net.netfilter.nf_conntrack_tcp_timeout_syn_recv = 60
net.netfilter.nf_conntrack_tcp_timeout_syn_sent = 120
net.netfilter.nf_conntrack_tcp_timeout_time_wait = 120
net.netfilter.nf_conntrack_tcp_timeout_unacknowledged = 3600
net.netfilter.nf_conntrack_udp_timeout = 30
net.netfilter.nf_conntrack_udp_timeout_stream = 180

Denmach sollten es 180 Sek, oder? Mit den 20Sek liege ich also gut :-D.

 

[sonyKatze]

Weil ich keine USG Pro habe, weiß ich nicht, in welche Rubrik UniFi unser VoIP nach SIP einordnet, also ob es SIP als „UDP-Stream“ erkennt. Am sichersten bist Du, wenn Du den Wert experimentell ermittelst … wäre auch interessant für andere Nutzer, zu wissen, welcher Parameter genau hier greift.

 

[urzani]

Ich habe leider keine Idee, wie ich das experimentell ermitteln sollte.

 

[sonyKatze]

Siehst Du meine hellblauen Text-Teile? Das sind Hyperlinks auf einen anderen Post … bin mir nicht sicher, ob die Style-Templates des Forums für alle Plattformen das richtig anzeigen. Dort in dem Post steht dann:
$ turnutils_natdiscovery -t -T 180 stun.antisip.com
Das Einfachste wäre ein Ubuntu 18.04 LTS oder neuer in einer virtuellen Maschine aufzusetzen und dort dann über
$ sudo apt install coturn
das Software-Package mit jenem Tool installieren. Erhältst Du auf „Response 1“ ein „STUN receive timeout..“, sind 180 Sekunden zu lang. Erhältst Du „Response 2“, hast Du einen Wert innerhalb der möglichen Zeitspanne. Du gehst dann auf 178 Sekunden … und auf 30 Sekunden … und auf 28 Sekunden.

Port-Forwarding führt dazu, dass Deine Grandstream für alle IP-Adressen auf der Welt ansprechbar ist. Je nachdem wie die Grandstream konfiguriert ist, akzeptiert diese dann solche Anrufe, was dann zu Spam-Anrufen führt.

urzani, für Dich weniger interessant, weil Du das schon gelöst hast. Aber für Jene, die hier über eine Internet-Suche vorbeikommen:

Grandstream → Web-Oberfläche → (Reiter) „Profile“ oder „Account“ → SIP → Security → Accept Incoming SIP from Proxy Only: Yes​

So überprüft Grandstream die IP-Adresse eingehender Anrufe. In älterem Modellen heißt der Parameter „Allow Incoming SIP Messages from SIP Proxy Only“ bzw „P243“. Bei neueren Modelle heißt dessen Configuration-Parameter „account.1.sip.validate.incomingServer“. Aus der Kategorie Security-through-obscurity stammen die folgenden drei Parameter:

• Validate Incoming Messages: Yes
  Eingehende Anrufe werden nach unbekannten† Kriterien überprüft. Meine Tests zeigen, wenn die SIP/SDP-Nachrichten valide sind (z.B. mit der App sip-tester erstellt), geht der Anruf durch. Daher reicht dies als Schutz allein nicht aus, vermeidet aber bereits einige der Anrufe.
• Check SIP User ID for Incoming INVITE: Yes
  Damit muss die User-ID eingehender Anrufe der User-ID in einem konfigurierten Konto übereinstimmen. Ein Angreifer muss lediglich herausbekommen, wie die SIP-User-ID lautet (die bei vielen Telefonie-Anbietern nur aus Zahlen besteht). Daher reicht dies als Schutz allein nicht aus, vermeidet aber bereits einige der Anrufe.
• SIP → Basic → Use Random SIP Port: Yes, bei neueren Modellen unter dem Reiter Settings → General
  Dieser Parameter greift nur dann, wenn man nicht TCP sondern UDP nutzt. Aktiviert öffnet ein Granstream für SIP nicht stur 5060 sondern irgendeinen Port. Ein Angreifer muss herausbekommen, welcher Port genutzt wird. Ein solcher gewürfelter Port ist lediglich von einem Angreifer im Heimnetz oder bei einem Port-Trigger oder als Exposed-Host nutzbar. Aber trotzdem sollte man nicht stur UDP-Port 5060 nehmen, weil viele NAT-Umsetzer einen Port nur einmal vergeben können und durch andere SIP-Telefone im Heimnetz bereits blockiert sein könnten. Der NAT-Umsetzer vergibt dann extern einen ganz anderen Port, was manche Telefonie-Anbieter irritiert, weil die Port-Angaben in den SIP-Nachrichten der Grandstream dann falsch sind. Oder der NAT-Umsetzer gibt gar keine Antworten zurück, weil er alle Antworten lediglich an den ersten Öffner des UDP-Ports 5060 weiterleitet.

Aber hier geht es nicht um IT-Sicherheit sondern um Schutz vor Phantom- bzw. Geister-Anrufen. Daher empfehle ich, alle vier Parameter einzuschalten. Trotzdem ist spannend, wie Grandstream dies begründet … alles Unfug. Wichtig(er) ist, eine Grandstream nicht ins öffentliche Internet zu exponieren. Scheint das unumgänglich, solltest Du die Ursache dafür ergründen, bevor Du extra deswegen an diesen Parametern hier herumschraubst. Einfach einen neuen Thread aufmachen und dann schaut sich die Foren-Community Deinen Fall an.

Wichtig: Diese vier Parameter sind für alle (aktiven) Konten einzuschalten, denn eine Grandstream überprüft nicht auf den zugehörigen Port. Anders formuliert: Ist aufgrund irgendeines Kontos ein Port zugänglich, werden erstmal alle SIP-Nachrichten akzeptiert. Erlaubt dann irgendein Konto die Nachricht, wird es ihm zugestellt. Völliger Murks, aber so denkt sich das Grandstream seit Jahrzehnten. Auch gilt obiges nicht nur für UDP sondern auch dann, wenn man TCP als SIP-Transport benutzt. Auch das zeigten meine eigenen Tests.

† In Grandstreams Security-Manuel findet sich die offizielle Erläuterung. Obiges habe ich durch eigene Tests ermittelt.