3CX Telefonie funktioniert nach Umzug auf neuen Server nicht mehr

[Gizzmo80]

Ich hab eben bemerkt, dass mein Laptop wohl die Anfrage verfälscht. Der hängt wohl die
Damäne noch an, daher wird falsch aufgelöst. Wobei ich mich wunder warum. Ich versuche
mal einen Reboot...

Vom iPad funktioniert es wunderbar, wie es soll.

Edit:
OK, ich hab das Verhalten mal gegoogelt und wenn ich hinter die URL einen Punkt setze dann löst mein Win10
Rechner auch korrekt auf. Wobei ich mir sicher bin, dass es gestern mal normal ging...

 

[fxbastler]

Edit:
OK, ich hab das Verhalten mal gegoogelt und wenn ich hinter die URL einen Punkt setze dann löst mein Win10
Rechner auch korrekt auf. ...

Das liegt an der default search domain. Wenn der Computer einer Domäne angehört, dann wird diese automatisch der Suchanfrage angesetzt. Mit z.B. einem Punkt wird das unterbunden wie du schon selber festgestellt hast.

 

[Gizzmo80]

OK, also bei mir funktionieren zumindest die stun2-eu.3cx.com und stun3-eu.3cx.com nicht. Diese lassen sich
nicht auflösen und ich bekomme dann auch irgendwann eine Meldung. Diese auf stun2.3cx.com und stun3.3cx.com
zu ändern wäre möglich. Aber so wie es aussieht lösen die stun-eu.3cx.com und stun.3cx.com auf 3 IP Adressen
auf und hier teilweise die selben, die anderen mit einer Zahl lösen nur auf eine IP auf.

Ist hier zu beachten, dass man lieber server mit jeweils einer IP nimmt? kann man u.U. auch nur einen eintragen,
der dann auf 3 unterschiedliche auflöst? oder soll man die Meldungen, dass mehrere Server mit der selben IP
verwendet werden ignoriert werden?

Ich bin jetzt mal hergegangen und habe stun2.3cx.com, stun3.3cx.com und stun4.3cx.xom eingetragen. Die lösen
alle auf nur eine IP und unterschiedliche auf.

Das scheint aber auch keine gute Idee, hier verweist es nun auch noch auf eine Amazon Adresse OK dann zurück.

 

[fxbastler]

OK, also bei mir funktionieren zumindest die stun2-eu.3cx.com und stun3-eu.3cx.com nicht. Diese lassen sich
nicht auflösen und ich bekomme dann auch irgendwann eine Meldung.

Da gibt es keine Antwort auf der 3CX?

Aber so wie es aussieht lösen die stun-eu.3cx.com und stun.3cx.com auf 3 IP Adressen
auf und hier teilweise die selben

ja, richtig

Entscheidend ist, dass die 3CX die FQDN auflösen kann und wenn die 3CX die STUN Server irgendwann (s.o.) abfragt auch die eigene IP von da zurück bekommt.

Merke: nslookup fragt nur den Cache ab. Falsche Frage / falscher Cache = falsche oder keine Antwort.
Alternativ ping oder tracert o.ä. benutzen. Achtung: viele Ziele sind nicht anpingbar.

STUN tickt nochmal ganz anders. Die Frage und Antwort bekommst du vmtl. nur mit einem Paketmitschnitt.

 

[Gizzmo80]

Danke Euch soweit für die Infos. Wieder etwas gelernt und immer dabei.

OK, aktueller Stand ist dass ich über nslookup nun meine IP sowol extern als auch intern zurück bekomme. Aber nun
ist das Aktivitätenprotokoll voll mit diesen Meldungen:

19.02.2025 09:04:04.270	There's another STUN server that resolves to the same IP: 147.135.193.83:3478/UNKNOWN_TRANSPORT fk=0 tgt=; ignored
19.02.2025 09:02:04.233	[CM306002]: There is no valid STUN server specified! External IP can not be resolved.

Das wäre mein STUN-Server Setting nun seit gestern Abend:




An dem eigentlichen Problemen:

- Call intern nach extern (Handy) geht raus + kann angenommen werden und hat Audio bidirektional, aber bricht nach
15s ab
- Call von extern kommt wohl nicht an der 3CX an, da weder die mailbox ran geht noch die Telefone klingeln und ich
auch in der 3CX nichts sehe

hat sich erstmal noch nichts geändert. Ich gehe jetzt nochmal die FireWall Einstellungen durch. Aber dem Grunde nach
hatte es ja mit der alten Instanz funktioniert und ich habe in der PFsense nun nur den Alias auf die neue IP im neuen
VLAN "Telefonie" gesetzt.

Meint Ihr, dass die Telekom aufgrund der vielen Neuverbindungen der letzten Tage hier u.U. in eine Art Sperrmodus für
meine VOIP Verbindungen gegangen ist? wobei die Trunks sich mit UDP ja, vermeintlich korrekt anmelden. Ich hatte
gestern auch mal einen Trunk neu angelegt, wobei das Call and Surf Template wohl automatisch auf TCP geht und laut
Info der Telekom und auch praktisch geht wohl nur UDP für SIP. Mit der Änderung auf UDP ging der auch wieder online,
aber sonst immer noch die selben Probleme.

Die Meldungen hier wundern mich noch etwas, aber ich glaube fast das hier nur der Start eines Service zu früh stattfindet,
da es ja eher um den Call nach außen geht und der geht ja zumindest für 15s.

 

[avraammich_3CX]

Hi @Gizzmo80,

Meldung mit dem Stun Server kannst du ignorieren da hier eine Dynamische IP verwendest.

An sich benötigen wir eine Statische IP sofern Telekom Trunks im Spiel sind,

Besagt/Betont Anleitung/en:

https://www.3cx.de/docs/adminhandbuch/sip-trunks/deutsche-telekom-call-und-surf/

 

[Gizzmo80]

Hi,
OK, das mit den Meldungen bzgl. STUN hatte ich schonmal gelesen, wobei die Meldung dass kein valider STUN
Server konfiguriert sei, mich etwas wundert.

Nach der Anleitung hatte ich ja auch schon vor v20 oder vielleicht sogar v18 auf meinem Raspi und nachdem dieser
nicht mehr unterstützt wurde, dann auch meinem Synology NAS die Konfig erstellt. Das war bisher auch bei beiden
Installationen eher "einfach". Aber aktuell mit dem Wechsel auf die ProxMox VM und auf das Telefon VLAN, keine
Ahnung was hier aktuell noch reinfunkt und die Anbindung ändert. Eben da ich ja eigentlich die FireWall Regeln
passend auf die anderen IP und VLAN geändert habe.

 

[Gizzmo80]

Ich habe wirklich keine Ahnung warum es nicht mehr geht. Ich habe heute nochmal mit den FireWall Regeln
gespielt aber ich finde den Grund nicht.

Hier die Forwarding Rules:




Hier die Outbound:




Die Einstellungen im DNS Resolver für den Host Override ist gemacht und der FireWall Check läuft voll durch.

Wenn ich von meinem 3CX Client auf dem Handy eines die beiden IP Verbindungen zur Gigaset N510 anrufe, dann
klingelt auch das DECT Telefon und wenn ich abnehme bleibt die Verbindung bidirektional für länger als 15s bestehen.
Die sind ja als 2 Nutzer angelegt und stellen dann quasi eine Weiterleitung der beiden Telekom Trunks zu den DECT
Telefonen dar. Wenn ich den Anruf nicht abnehme dann lande ich auch auf der Mailbox auf der 3CX.

Nur von außen sind meine beiden Rufnummern nicht erreichbar und bei einem Anruf von innen nach außen bricht die
Verbindung nach exakt 15s ab. UDP keepalive ist aber sogar in der 3CX an, die UDP Timeouts sind angehoben in der
PFSense.

Ich habe es nun auch mit "statischer IP" versucht, im Grunde wechselt meine Public IP bei der Telekom ja auch eher
selten solange die Internetverbindung steht. Aber es ist egal ob ich den STUN-Server aktiviere oder über statische IP
einstelle.

 

[bitn2]

Ist die IP 172.23.11.1 die IP der 3cx? Das ist doch in der Regel eher die des Gateways...

 

[Gizzmo80]

Also was auch funktioniert, Handy nur mobile Daten kann sich mit der 3CX Telefonanlage verbinden und ich
kann auch auf diesem Weg die "Nutzer" der beiden Verbindungen zu meinen DECT Telefonen zuhause
anrufen. Die Verbindung ist bidirektional und länger war min. 60 Sekunden.

Wobei ich glaube die Verbindung geht ja rein über 5001 und den Tunnel mit 5090, richtig? auch wenn ich
quasi von extern mit 3CX Client auf dem Handy telefoniert hatte.

 

[Gizzmo80]

Ist die IP 172.23.11.1 die IP der 3cx? Das ist doch in der Regel eher die des Gateways...

Ist sie, ich lege die Gateways immer auf .254

 

[bitn2]

Hmm, IPv6 ist deaktiviert auf der 3cx? Das kann auch gerne zu Problemen führen. Ansonsten müsste man sich mal das Log auf Ausführlich angucken, mir gehen auf die Ferne etwas die Ideen aus.

 

[Gizzmo80]

Mir gehen die auch in der Nähe aus ich hab schon ganz wilde Sachen gemacht wie DECT Basis zurücksetzen
und neu provisionieren usw. Was eigentlich klar war, dass das nichts ändern wird.

Bzgl. IPv6 deaktiviert, dem Grunde nach sollte es so sein. Ich habe im Debian der VM zumindest in der sysctl.conf
diese Werte gesetzt:

• net.ipv6.conf.all.disable_ipv6 = 1
• net.ipv6.conf.default.disable_ipv6 = 1
• net.ipv6.conf.lo.disable_ipv6 = 1

Und seit dem sehe ich in der Übersicht des VM im ProxMox auch:



Der einzige Punkt über den ich schon nachgedacht hatte ob es ein Problem ist wenn IPv6 während der Installation
von 3CX aktiv, aber nicht genutzt (in meinem Netzwerk hab ich normal alle IPv6 Schnittstellen aus und keinen
IPv6 DCHP laufen, die FW sperrt auch IPv6) ist. Das war auch auf meiner vorherigen Instanz auf dem Synology
NAS immer nur IPv4.

Da ich ja erst nach der Installation vom Debian die IPv6 deaktivieren könnte, ist 3CX immer noch mit
aktiviertem IPv6 installiert worden. Ich hatte nach dem Debian nicht abgebrochen, IPv6 abgeschaltet
und dann 3CX installiert.

 

[Gizzmo80]

OK, ich habe endlich verstanden wie ich mehr Infos in die Log bekomme. Muss gestehen das war mir bisher
ein Rätsel. Ich hab jetzt mal auf "ausführlich" gestellt und schau es mir nochmal an.

 

[Gizzmo80]

Also was mich wundert ist die Registrierung meiner Trunks, die ja vermeintlich OK verläuft. Aber
ich sehe in der Log:

10000(@Deutsche Telekom 76er[<sip:[email protected]:0/UDP>])

Warum Port "0" ? bzw. klar ich muss damit die Registrierung erfolgt unter Serverdetails "Autom. Erkennung" für den
Registrar beim Port einstellen. Wenn ich auf 5060 einstelle, verbindet sich der Trunk nicht. In der Anleitung zu Call and Surf
sehe ich diesen Einstellungsbereich nicht und bin mir nicht sicher was man einstellen müsste.

 

[bitn2]

Das muss auf automatisch stehen da die Telekom Server nur noch über SRV Einträge erreichbar sind. Also alles korrekt.

 

[Gizzmo80]

Also ich hatte keine Idee mehr und habe heute nicht nur den Trunk oder so mal neu aufgesetzt, sondern
gleich die gesamte 3CX Telefonanlage und dabei auch gleich ohne mein Backup sondern von Grund auf
neu konfiguriert.

Die Konfig war schon älter, denke von v16 über die Update mitgeführt und zwischenzeitlich auf unter-
schiedlichen Systemen wie Raspi, Synology und nun ProxMox. Keine Ahnung wo es da schief
gegangen ist, aber jetzt funktioniert es wohl erstmal wieder.

Ich habe wieder meine beiden wesentlichen Trunks in Verbindung mit den DECT Telefonen in Funktion.
Dies sowohl eingehend mit Unterscheidung der beiden Trunks, als auch ausgehend. Die ersten Telefonate
hatten auch 2-3 Minuten funktioniert.


Mal sehen ob es dabei bleibt und was ich ggfls. noch vergessen habe...


Danke auf jeden Fall für die Hilfestellungen, auch wenn es dem Grunde nach wohl eher eine vermurkste
Konfig war.