3CX Telefonie funktioniert nach Umzug auf neuen Server nicht mehr

[Gizzmo80]

Hallo,

nachdem ich nun nach langer Recherche keine Ahnung mehr habe was ich noch testen und ändern soll, versuche ich es
doch mal hier. Ich hoffe jemand hat noch eine Idee.

Hintergrund:
- mein 3CX lief bisher auf einem Synology NAS in einem Container, es ist eine 4 Calls free Lizenz und wohl noch aktiv und
OK
- auf dem NAS lief es schon länger korrekt
- nun habe ich einen ProxMox Server aufgesetzt und in einer VM die 3CX neu aufgesetzt und darin das Backup von der
Synology Instanz verwendet
- die 3CX Instanz läuft unter Debian12
- die neue 3CX Instanz ist nun in ein anderes VLAN (Telefonie), in welches sie sowieso schon immer gehört hätte, um-
gezogen
- ich habe einen Telekom Magenta XL Internetanschluss und verwende 3 Trunks mit 3 unterschiedlichen Nummern


Dem Grunde nach sieht eigentlich alles OK aus, zumindest für mich d.h.:
- meine Trunks melden sich vermeintlich korrekt an und bleiben es auch (alle grün)
- ich habe in meiner PFsense FireWall alle Regeln inkl. Split DNS und HairPin DNS geändert, d.h. auf das andere VLAN/IP
und der FireWall Checker ist auch alles OK
- meine Gigaset N510 Pro mit den 2x DECT Telefonen ist auch wieder verbunden, sowie meine 3CX Apps auf Handy und
iPad
- dem Grunde nach war es ja vorher auf dem Synology NAS auch eine funktionierende Lösung

meine Probleme sind aktuell:
1. wenn ich von intern auf mein Handy anrufe, dann funktioniert es, ich kann abnehmen und ich habe Audio. Aber die
Verbindung bricht nach exakt 15 Sekunden ab
2. von extern ist meine 3CX nicht erreichbar, es klingelt nicht und auch wenn die Weiterleitung auf die Telefone nicht
gehen würde, dann müsste die Mailbox rangehen. Aber mein Handy zeigt nur "wählt" ohne jeglichen akustischen
Signale und bricht dann ab.


Was ich u.a. neben vermutlich noch weiteren vielen Versuchen gemacht habe:
- IP meiner Debian VM ist IPv6 ausgeschalten und ich habe den Google DNS 8.8.8.8 zugewiesen
- ich habe mit den FireWall Regeln hin und her versucht, diese und die 3CX Instanz mehrfach neu gestartet
- ich habe auch die 3cx Instanz gestoppt und etwas gewartet, allerdings vermutlich nicht ganz einen Tag, falls irgendwelche
Sperren bei der Telekom vorhanden wären
- ich bin nochmal alle Einstellungen durchgegangen und hab diese auch mit der Instanz auf der Synology verglichen, aber
ich finde keine Unterschiede. Wobei ich mittlerweile die Trunks auf der alten Instanz gelöscht habe um hier eventuell
Überschneidungen zu verhindern
- ich habe auch mal die Telekom Diagnose für meinen Anschluss bzgl. Telefonie durchgeführt und dabei wurde mein Anschluss
neugestartet. Ich habe aber noch nicht
mit der Telekom Kontakt aufgenommen
- ich habe SecureSIP auch mal ausgeschaltet, aber das hatte nichts geändert und es war ja früher auch an und ist es auch
wieder


Sicherlich in Hinweis könnte der Eintrag im Aktivitätenprotokoll sein:

18.02.2025 10:46:32.914	Dev(585514768):[sip:[email protected] / TelNummer2]: (!) No transport is found for destination: <sip217.0.148.69:5060/UDP>
18.02.2025 10:46:32.891	Dev(1635903217):[sip:[email protected] / TelNummer1]: (!) No transport is found for destination: <sip217.0.148.69:5060/UDP>
18.02.2025 10:46:32.019	Dev(1069640488):[sip:[email protected] / TelNummer3]: (!) No transport is found for destination: <sip217.0.148.69:5060/UDP>
18.02.2025 10:46:32.019	Dev(1069640488):[sip:[email protected] / TelNummer3]: (!) No transport is found for destination: <sip217.0.148.69:5060/UDP>
18.02.2025 10:46:32.019	Dev(1635903217):[sip:[email protected] / TelNummer1]: (!) No transport is found for destination: <sip217.0.148.69:5060/UDP>
18.02.2025 10:46:32.019	Dev(1635903217):[sip:[email protected] / TelNummer1]: (!) No transport is found for destination: <sip217.0.148.69:5060/UDP>
18.02.2025 10:46:32.019	Dev(585514768):[sip:[email protected] / TelNummer2]: (!) No transport is found for destination: <sip217.0.148.69:5060/UDP>
18.02.2025 10:46:32.019	Dev(585514768):[sip:[email protected] / TelNummer2]: (!) No transport is found for destination: <sip217.0.148.69:5060/UDP>

Die STUN Server Meldungen scheinen ja bei einer dynamischen IP normal zu sein:

18.02.2025 10:46:32.995

There's another STUN server that resolves to the same IP: 212.227.67.34:3478/UNKNOWN_TRANSPORT fk=0 tgt=; ignored

 

[bitn2]

Die alte Instanz ist aber ausgeschaltet oder?

 

[Gizzmo80]

Ja, war nur zwischenzeitlich mal kurz an um die Einstellungen zu vergleichen. Mittlerweile hat die
alte aber auch zumindest keine Trunks mehr.

 

[bitn2]

Die alte Instanz ist aber ausgeschaltet oder? Die muss ausgeschaltet sein... Die Portweiterleitungen sind eingerichtet? Firewallcheck läuft durch?

 

[Gizzmo80]

Ja, ja und läuft durch

 

[bitn2]

Der STUN Server ist falsch, den bitte mal wieder korrigieren, sonst funktioniert der check nicht.

 

[bitn2]

Prüfe mal folgende Einstellungen, interne IP und die Stunserver

 

[Gizzmo80]

Hmm, warum auch immer hast Du recht dass aktuell die Public IP nicht mehr korrekt übergeben wird.
Das war gestern noch anders. Ich habe andere STUN-Server eingetragen den t-online, den schlund und gmx.
Ich konnte die 3CX stun gestern nicht pingen und diese schon.

dachte aber über nslookup wurde richtig verwiesen, wobei ich zumindest von intern und extern über die FQDN
auf den Webclient komme... aber nslookup verweist eigentlich falsch...

 

[Gizzmo80]

Aber der FW-Check geht normal durch...

 

[bitn2]

Du darfst die stun server nicht ändern. Sonst funktioniert der dyndns nicht mehr. Deswegen bitte korrigieren.

 

[Gizzmo80]

OK, meine in diversen Beiträgen gelesen zu haben dass man dem Grunde nach jeden STUN-Server verwenden
kann und gerade der vom Provider wäre auch manchmal eine gute Idee.

bin jetzt wieder auf stun1.3cx.com / stun2.3cx.com / stun3.3cx.com

Aktuell scheint sich aber nichts an der Situation geändert zu haben.

 

[bitn2]

Trag mal bitte die stun server von meinem Screenshot ein und stelle danach die IP mal auf feste IP und wieder zurück. Dann kann es je nach Lizenz bis zu 6 Stunden dauern.

 

[Gizzmo80]

OK, wäre soweit geändert und hab auch alle Dienste 1x neugestartet. Aber da ich ja die kostenlose Lizenz habe
warte ich jetzt wohl mal bis morgen. Aktuell hat sich ebenfalls noch nichts geändert.

 

[bitn2]

Stelle einmal auf feste IP um, speichern und wieder zurück.. Wenn alles passt sollte das recht schnell gehen.

 

[Gizzmo80]

Wie kontrolliere ich es dann ob es passt, über nslookup auf die FQDN ?

 

[bitn2]

Wie kontrolliere ich es dann ob es passt, über nslookup auf die FQDN ?

Von intern muss das die interne ip ergeben und von extern die externe.

 

[Gizzmo80]

OK, dann war ich schon richtig. Aber aktuell ist das immer noch eine 64..190.63.222 IP, also
nicht meine und intern löst auch darauf auf.

Wobei, was ich gerade sehe alles wird darauf aufgelöst auch google.de, hmmm.

 

[fxbastler]

Aber da ich ja die kostenlose Lizenz habe warte ich jetzt wohl mal bis morgen. Aktuell hat sich ebenfalls noch nichts geändert.

Bei der kostenlosen 3CX dauert es 24 h bis zur Aktualisierung, außer du wechselst manuell auf feste IP und wieder zurück (soweit das wie früher noch funktioniert). Bei einer PRO dauert es 6 h, bei einer ENT 5 min..

 

[bitn2]

Wie fragst du denn ab? Poste mal nen Screenshot. Von extern musst du auch von externe machen, intern muss er deine interne ip auflösen wenn du korrekt und wie gefordert split dns konfiguriert hast.

 

[bitn2]

Bei der kostenlosen 3CX dauert es 24 h bis zur Aktualisierung, außer du wechselst manuell auf feste IP und wieder zurück (soweit das wie früher noch funktioniert). Bei einer PRO dauert es 6 h, bei einer ENT 5 min..

Funktioniert noch genau so.