DNS error resolving FQDN

[njullmann]

Hallo liebe Community,

wir haben insgesamt 8 3CX Instanzen, die wir betreuen. Alle laufen vollkommen problemlos. Ausser einer....
Bei dieser erscheint mehrfach am Tag:

• Registration at Deutsche Telekom SIP-Trunk (NGN) has failed. Destination (sip:217.0.26.131:5060;transport=TCP;lr) is not reachable, DNS error resolving FQDN, or service is not available.
  
  SIP Server ID: 12293 29.03.2021 19:27:19
• Registration at Deutsche Telekom SIP-Trunk (NGN) has failed. Destination (sip:217.0.26.131:5060;transport=TCP;lr) is not reachable, DNS error resolving FQDN, or service is not available.
  
  SIP Server ID: 12293 29.03.2021 17:13:54
• Registration at Deutsche Telekom SIP-Trunk (NGN) has failed. Destination (sip:217.0.26.131:5060;transport=TCP;lr) is not reachable, DNS error resolving FQDN, or service is not available.
  
  SIP Server ID: 12293 29.03.2021 17:10:16
• Registration at Deutsche Telekom SIP-Trunk (NGN) has failed. Destination (sip:217.0.26.131:5060;transport=TCP;lr) is not reachable, DNS error resolving FQDN, or service is not available.
  
  SIP Server ID: 12293 29.03.2021 17:06:38
• Registration at Deutsche Telekom SIP-Trunk (NGN) has failed. Destination (sip:217.0.26.131:5060;transport=TCP;lr) is not reachable, DNS error resolving FQDN, or service is not available.
  
  SIP Server ID: 12293 29.03.2021 17:03:01

und nach ein paar Minuten ist der ganze Spuk wieder vorbei. Dummerweise brechen dabei alle Telefongespräche ab.

In all unseren Installationen ist als Registrar: sip-trunk.telekom.de und als Proxy: reg.sip-trunk.telekom.de hinterlegt und wie gesagt, keine Probleme mit diesen Anlagen.

Die Namensauflösung auf dem "problematischen 3CX Server"verläuft auch problemlos:

dig _sip._tcp.tel.t-online.de SRV

; <<>> DiG 9.11.5-P4-5.1+deb10u3-Debian <<>> _sip._tcp.tel.t-online.de SRV
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 47842
;; flags: qr rd; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;_sip._tcp.tel.t-online.de. IN SRV

;; ANSWER SECTION:
_sip._tcp.tel.t-online.de. 1482 IN SRV 30 0 5060 h2-epp-110.edns.t-ipnet.de.
_sip._tcp.tel.t-online.de. 1482 IN SRV 20 0 5060 d-epp-110.edns.t-ipnet.de.
_sip._tcp.tel.t-online.de. 1482 IN SRV 10 0 5060 f-epp-100.edns.t-ipnet.de.

;; Query time: 0 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
;; WHEN: Di Mär 30 07:33:09 CEST 2021
;; MSG SIZE rcvd: 190

dennoch diese ständigen Abbrüche.

Der einzige Unterschied bei dieser Installation ist, dass als Router kein Lancom Router sondern eine einfach Fritzbox 7530 als Router installiert ist und der SIP Port der 3CX auf 5062 umgeleitet ist. Aber das hat ja keinen Einfluss auf den DNS Error.

Jemand ähnliche Erfahrungen gemacht oder eine Idee??

Vielen Dank

 

[VoIPexpert]

Hallo, das Problem kenne ich an einer Telekom-Leitung und ist keine Seltenheit.
Bei einem Kunde hatte ich die WatchGuard Firewall Updaten und bei einem anderen sogar ersetzen müssen, damit das Problem gefixt wurde.

Versuch mal ein Firmwareupdate der Fritzbox und ändere den DNS auf 8.8.8.8

 

[njullmann]

danke für die antwort.

fritzbox ist bereits die neueste version und dns server sind alle durchprobiert von 194.25.2.129 bis 8.8.8.8

und wie gesagt 7 anlagen laufen ohne murren, nur diese nicht :-\

ist aber auch die einzige an einer fritzbox.......

 

[Trust]

Das gleiche Problem habe ich auch.
Eigenartig ist, dass es ca. 2 Mal die Woche auftritt.
Sowohl bei Telekom als auch Easybell Siptrunks

 

[njullmann]

Das Problem ist tatsächlich behoben. Der Telekomtechniker bestätigte mir Störungen auf der Leitung und hat "neu konfiguriert" (was immer das genau heisst ;-) ), hat dann den port resettet und seitdem ist der fehler nicht mehr aufgetreten.

 

[njullmann]

Es war ein kurzes Glück...... Zwei Tage danach kehrte der derselbe Fehler zurück.
Mehrmals am Tag. Mittlerweile mehrmals in der Stunde.
Hat jemand ähnliche Erfahrungen gemacht oder kann helfen?

DNS Namensauflösung funktioniert unter dem darunterliegenden Linux tadellos........

 

[VoIPexpert]

also mich würde auch mal interessieren was das Problem ist und wie man es behebt, denn auch ich habe einige Installationen mit diesem Problem.
Was bei allen gleich ist: - Alle nutzen die Internetleitung von der Telekom (Business Tarif mit fester IP).
Was nicht das Problem sein kann: Firewall/Router. Denn diese sind immer unterschiedlich und habe ich teils auch schon getauscht. Nach einem Reboot (Internetneueinwahl) funktioniert die SIP-Registrierung wieder.

 

[sebastianadams]

Wir haben das gleiche Problem mit einem Easybell Trunk. Auch das manuelle "Alle aktivieren" hilft in der Situation nicht.

Wir haben mit Easybell Rücksprache gehalten und dort die Antwort erhalten, dass ein Reg-expired vorlag, da kein Keep Alive gesendet wurde. Das führte dazu, dass die Anlage deregistriert wurde.

Ich habe mich während des Ausfalls auf die VM eingeloggt und konnte erfolgreich die URL des Trunks anpingen. Deswegen gehe ich davon aus, dass der DNS Eintrag erfolgreich aufgelöst werden kann und keine Netzwerkprobleme vorlagen.

Zum Setup.:
Wir betreiben die VM auf einem Server Cluster der Telekom mit fester IP Adresse. Als Failover DNS Server ist ebenfalls die 8.8.8.8 hinterlegt.

Ich vermute inzwischen, dass es sich um einen Bug in 3CX handelt. Habt ihr Ideen, wie man weiter vorgehen kann bzw. ob man hier Hilfestellung vom Hersteller bekommt?

 

[bitn]

Bringt es evtl. was die Option Keep-Alives zu aktivieren unter den Netwerkeinstellungen ?

 

[sebastianadams]

Das klingt sehr vielversprechend! Ich werde es sofort testen.

 

[sebastianadams]

Gerade ist das Problem erneut aufgetreten. Ich hab die Keep-Alive Einstellung wenige Sekunden nach dem Auftreten aktiviert und der Trunk hat sich sofort wieder verbunden. Es scheint also geklappt zu haben. Vielen Dank für die Hilfe!

Ich habe zusätzlich ein Ticket beim 3CX Support aufgemacht, was aber bis jetzt keine wirklichen Erkenntnisse geliefert hat. Dort kam nur die Antwort, dass bei easyBell kein TLS Trunk unterstützt würde und man darauf achten sollte, dass das Root Zertifikat korrekt sei. Beide Hinweise erscheinen mir wenig zielführend, wenn man beachtet, dass das Problem nur spontan auftritt und auch nach einigen Minuten ohne zutun wieder verbunden wird.

 

[VoIPexpert]

Da es immernoch Probleme gibt würde ich das Thema hier nochmals aufgreifen.
Ich denke es ist auch kein 3CX Problem!!!! Das Problem tritt auch bei anderen Anlagen auf und meistens ist immer ein Telekom Internetanschluss dahinter.

Also bei einigen Kunden hat das Keep-Alive setzen nicht geholfen. Ich hab ein Kunde mit folgender Umgebung:

Szenario 1:
- 3CX Anlage
- SIP-Trunk von Peoplefone
- Internetleitung von Telekom
- WatchGuard Firewall

Jede Nacht muss die Firewall neu gestartet werden, da der SIP-Trunk nicht mehr online geht.
Die Firewall wurde auch bereits ausgetauscht.
Zuvor war ein Telekom NGN Trunk angebunden und auch da war das Problem vorhanden.

Szenario 2:
Kunde mit andere Anlage
- SIP-Trunk von Telekom (NGN)
- Internetleitung von Telekom
- Sophos Firewall

Sip-Trunk wird als aktiv dargestellt, Anrufe gehen aber weder raus oder rein.
Neustart der Anlage ist notwendig, damit alles wieder funktioniert.

Szenario 3:
- 3CX Anlage
- SIP-Trunk von Telekom (NGN)
- Internetleitung von Telekom
- Sophos Firewall

Hier wurde eine Anlage von einem anderen Hersteller (auch VoIP) durch eine 3CX abgelöst und erst neu eingerichtet. Es gab bei der Inbetriebnahme das Problem, dass eingehende Anrufe erst gar nicht an der 3CX ankamen. Mit der alten Anlage lief alles! Ein Anruf bei der Telekom ergab ein Fehler auf der Leitung. Der Techniker lies eine "rekonfiguration" der Leitung durchführen. Danach gingen die Anrufe sauber ein. Dieser Fehler lässt mich auf allgemeine Routingfehler bei der Telekom schließen, die evtl. auch für das Problem mit den nicht mehr verbindenden SIP-Trunks verantwortlich sein können. Aber das ist eher eine Theorie. Fakten wären in diesem Fall mal schön, da wohl einige davon betroffen sind und als Lösung nachts immer die Anlage oder die Firewall neu starten müssen.

Fazit:
Immer wenn ein Telekom-Anschluss angebunden ist, gibt es diese Probleme

 

[SchrammE]

Hi.

Wie sehen denn die TCP-/UDP-Timeout-Einstellungen auf deinen UTMs aus?

 

[fxbastler]

Hallo,

das Problem ist auch bei uns hier und da vakant. Es tritt ausschließlich an den 3CX ohne statische ISP IPv4 auf. Es tritt auch bei 3CX Enterprise Installationen auf.

Jede Nacht muss die Firewall neu gestartet werden, da der SIP-Trunk nicht mehr online geht.
Die Firewall wurde auch bereits ausgetauscht.

Der Neustart des Modem reicht i.d.R.. Ein künstlicher reconnect per Software reicht oft nicht. Wir experimentieren seit geraumer Zeit mit verschiedenen STUN Servern, Überwachung der Erreichbarkeit (nach Meldung Fehler bei Registrierung der 3CX usw.) herum - bisher ohne dauerhaften Erfolg. Entweder Schaltuhr am DSL Modem oder dessen Reboot per Software. Das hilft eine Zeitlang. Sonst E-Mail Benachrichtigung, Auswertung und als Trigger diese Aktion auslösen. Das funktioniert dann. Schön sieht anders aus.

Das ist auch die Antwort auf die Szenarien 2 und 3.

Wir waren zwischenzeitlich kurz davor einen eigenen STUN Server für diese unsere Kunden aufzusetzen. Aber auf Grund der geringen Masse ggb. des Aufwandes und der alternativen Lösungen haben wir das nicht umgesetzt.

 

[coLumBo]

Also ich muss das ganze hier einmal wieder vorholen. Wir haben seit letzter Woche Probleme mit unserer eigenen Anlage.

Wir haben eine 3cx Linux v18 auf einem VMware Hypervisor. Eine Sophos Firewall mit nun Version V20. Es wurde hier ein Firewall Update aufgespielt (mitte letzter Woche). Wir haben einen Peoplefone Trunk und mitten am Tag zu unterschiedlichen zeiten geht der Trunk Offline. Neustart der Anlage bzw. SIP Dienste bringt hier nichts. Beim Firewall Check während der Downtime wird mir ein Problem auf 5060 NAT angezeigt. Alle anderen Ports sind weiterhin OK. Nach unbestimmter Zeit (maximal 60 Min) geht dann wieder alles. FW Check läuft ohne Probleme durch und Sip kann wieder verbunden werden.

Im Protokoll der Firewall sehe ich eine Anfrage der Anlage bei sips.peoplefone.de mit 5060 um 12:32 Uhr. Diese Zeit wurde mir auch mit 3-4 Sekunden unterschied bei Peoplefone so bestätigt. Anschließend sehe ich im Protokoll nichts mehr über 5060. Bei Peoplefone kommt auch nichts mehr an. In der Weboberfläche sehe ich natürlich nach drücken auf "Anmeldung aktualisieren" eine Zeit für "Anfrage gesendet". Wie oben beschrieben ist diese aber nicht im FW Protokoll zu sehen.

Nach Neustart der FW hat sich der Trunk sofort wieder verbunden(Bisher nur 1x getestet). Ich habe jetzt auch etwas über den UDP Timeoutstream gefunden bei Sophos Firewalls. Dieser ist Standardmäßig auf 60 eingestellt. Bisher hatten wir damit noch keine Probleme. Nun habe ich es auf 150 erhöht, danach ist es aber schon wieder aufgetreten.

Im Ereigniss der 3cx sehe ich auch, wie hier im Startpost beschrieben, diesen Fehler mit DNS Auflösung. Ich kann genauso wie er sagte weiterhin auf der Anlage direkt auflösen. Mir kommt es so vor, als ob der 5060 Port "fest steckt". Bin mir nicht sicher ob es etwas mit 3cx oder mit der FW zu tun hat. Das Update vor dem Fehlerstart deutet natürlich auf FW hin.

Gibt es eine Möglichkeit außer SIP Dienst neustarten auf der 3cx, eine Neuverbindung des SIPS auszulösen?

Achja Keep-Alive 30 ist bei uns schon immer Aktiv.

MFG und ein schönes Wochenende.

 

[fxbastler]

Gibt es eine Möglichkeit außer SIP Dienst neustarten auf der 3cx, eine Neuverbindung des SIPS auszulösen?

Gegenfrage: Reicht es in so einem Fall, in der 3CX den SIP Trunk zu markieren und dann mit 'Anmeldung aktualisieren' den Trunk wieder zur Funktion zu bewegen?

Nachtrag:

Achja Keep-Alive 30 ist bei uns schon immer Aktiv.

ist bei uns aus

 

[coLumBo]

Sorry das hab ich wohl vergessen. Anmeldung aktualisieren bringt mir nur eine neue "Anmeldung gesendet" Zeit. Leider wird dadurch der SIP nicht wieder verbunden.

Ich kann gerne einmal das Keep-Alive entfernen. Bisher hatten wir damit noch nie Probleme.

 

[Trust]

Bei uns seit Jahren das gleiche Problem.

- Keep Alive diverse Werte getestet.
- DNS 1.1.1.1, 8.8.8.8, 9.9.9.9, 9.9.9.12 alles durch
- Uplinks von verschiedenen Providern getestet.
- mehrere Firewalls ausprobiert

bringt alles kein Erfolg
Wir haben nur Easybell und Telekom im Einsatz.
Das Seltsame ist auch, manchmal rauchen von 20 Easybell Trunks nur 5 oder so ab.

 

[ade]

Eventuell hilft es wenn man das Feld Registrar wie folgt ändert: statt sip.easybell.de voip.easybell.de eintragen.

Link zu Support von Easybell https://www.easybell.de/hilfe/frage...ns-srv-bei-easybell-voip-anschluessen-nutzen/

 

[Trust]

Hi,
danke für deine Antwort. Ich habe bei 10 Trunks sip.easybell.de und bei 10 Trunks voip.easybell.de eingetragen.
Bringt leider keine Besserung