Toggle sidebar Toggle sidebar

Verbindungsprobleme mit Einstellung "dynamische IP"

Es bleibt fast nichts anderes übrig. Wir kochen ja auch nur mit Wasser. Dennoch geht es sofort. Naja, meistens, bei der Telekom halt nicht so oft wie bei anderen und das hält auch nicht so lange an. Aber es geht.
 
Die Anleitung sagt aber auch:

Hinweis: Zur korrekten Registrierung und reibungslosen Nutzung von All-IP-Trunks ist eine statische IP-Adresse erforderlich. Die 3CX Telefonanlage muss im entsprechenden Modus betrieben werden.
 
  • Like
Reaktionen: Ralf_HD, bitn2 und mbehrens
Das muss ich überlesen haben - aber es dürfte ja bekannt sein, dass diese Tarife keine statische IP haben?!

Ich frage mich jetzt, wieso es bei fx funktioniert und bei mir nicht... Ich habe die Trunks auch schon komplett neu angelegt, das hilft auch nicht. Hab ich da irgendwo ne Einstellung falsch, die bei dir korrekt ist?! Wo könnte ich noch nachsehen und testen?
Es hat ja auch jemand aus dem Telekom-Forum das Ganze nachgespielt und er konnte bestätigen, dass "die 3CX auch bei der v20 in der Einstellung Dynamische öffentliche IP im Contact Header den FQDN übermittelt statt der öffentlichen IP"
 
@Saarlaender: Ich habe das gleiche Problem bei meiner 3cx V20.
Hast Du vieleicht schon eine Lösung?

Bei mir hilft es, wenn ich nach einem Neustart des debian Servers nur den “3CX PhoneSystem 01 SIP Server“ Dienst restarte.
 
Update zu @Saarlaender
Company Flex Deutsche Telekom und Betrieb der PBX v20 im dynamischen IP Modus kann den Sip-Trunk zur Telekom nicht aufbauen.
Es führt folgendem Fehler "Call or Registration to Deutsche Telekom (CompanyFlex - Cloud) has failed. sip:[email protected];transport=TLS replied: 403 Forbidden; from IP:217.0.149.208:5061 "
Der Response Server ändert sich immer - nicht wundern- Forbidden kommt von wechselndend Server IPs
--> Lösung Umstellung auf fixe IP Modus der PBX - Trunk läuft sofort
In Version 20.0 Update 3 (Build 806 Release) geht es mit dem Template nicht - ich vermute auch das der Header anders "bestückt" wird - wie die Vorredner beschreiben.

Wie immer wichtig ist Anleitung genau lesen !!!
  • Eine statische IP-Adresse wird benötigt. Die 3CX Anlage muss im entsprechenden Modus betrieben werden.
Das stimmt nur teilweise aber unumgänglich ist: Die Anlage muss zwingend im IP Statischen Modus betrieben werden. Ändert sich die IP, weil dem Anschluss nicht eine Statische IP zugeordnet wurde - geht der Trunk weiterhin - nur der Zugriff selbstverständlich auf dei PBX nicht mehr, weil logischerweise keine FQDN aktualisierung stattfindet.

Nach langem Suchen haben wir das nun gelöst. Hoffentlich bleibts Euch erspart.
oder der Header irgendwann angepasst.
 
Ich habe mein Problem lösen können und seit ein paar Tagen läuft meine 3CX V20 stabil. Der Fehler „Forbidden (403)“ ist nicht mehr aufgetreten.

Die Ursache: In meiner UDM waren die DNS Server 8.8.8.8 und 1.1.1.1 fest eingestellt.

Nachdem ich die DNS-Einstellungen auf automatisch gesetzt hatte, werden jetzt die DNS-Server der Telekom verwendet.

Mein Setup:
- Telekom DSL MagentaZuhause L
- Dynamische IP
- SIP Trunc Registrierung per UDP
 
Trennung des Sip Trunk Company Flex und Neuverbindung - mehrfach am Tag
Wir haben nun das Problem dass sich der SIP Trunk bis zu 5 mal am Tag sich kurz trennt und gleich wieder verbindet. Die Internetverbindung läuft durchgehend weiter.
Habt Ihr einen Ansatz?
 
Hermicus schrieb:
Wir haben nun das Problem dass sich der SIP Trunk bis zu 5 mal am Tag sich kurz trennt und gleich wieder verbindet. Die Internetverbindung läuft durchgehend weiter.
Zum Vergrößern anklicken....
Da könnten die Timeouts auf der Firewall nicht stimmen.
 
Ich muss das Thema nochmal aufgreifen!
Würde gern alte Anlage bei mehren kleinen Kunden gegen eine kleine Pro 4SM - 3CX austauschen.

Davon haben viele aber einen Telekom-Anschluss mit KEINER festen IP.

Ich weiß in der Anleitung steht: "reibungslosen Nutzung von All-IP-Trunks ist eine statische IP-Adresse erforderlich".
Wenn ich in der Anlage von feste IP auf dynamisch umstelle, sendet die 3CX den FQDN. Das mag die Telekom nicht.
Kann ich denn nicht einfach irgendwo einstellen, dass dort die "aktuelle" IP gesendet wird.

Dann wäre das Thema doch vom Tisch!

Eine feste IP wird sonst nie benötig und ein Tarifwechsel bedeutet immer mehrkosten von ca. 30 Euro im Monat = 360 Jahr. (das ist den meisten dann zu teuer) Das ist ja schon der Preis für die Pro Lizenz.:)
 
Wie ist die Frage?

Du bekommst dennoch ungefragt Hinweise. :)
Wir haben auch noch eingie wenige kleine Kunden mit billigstem Telekom Anschluss für zu Hause: einzelne MSN und dyn. IP. Deren 3CX Netzwerkeinstellung steht durchgehend auf dynamisch. Das funktioniert seit Jahren. Manchmal müssen wir ein klein wenig nachhelfen, indem wir das DSL Modem nachts zeitgesteuert per ssh neu starten lassen oder (besser) mit einer Zeitschaltuhr zwangsweise für kurze Zeit stromlos machen. Wenn es denn einen IP Wechsel geben kann, dann erzwingen wir so den Zeitpunkt. Allerdings sind das durchgehend 3CX ENT Lizenzen. Ich weiss aktuell nicht wie sich das bei einer Pro verhält. Aber das kannst du ja testen.

Alternativ kann man per xapi die Netzwerkeinstellungen ändern: z.B. per Skript täglich nachts die ext. IP holen, mit der IP der 3CX vergleichen, bei Differenz die akt. IP eintragen usw.. Man kann auch per Skript zw. statischer und dynamischer IP hin und her wechseln. Alles wie man will. Es muss nur eine Stelle geben wo so ein Skript laufen kann. Auch die 3CX selber mit Perl Skript bietet sich an oder Powershell wenn es eine Windows 3CX ist.
 
fxbastler schrieb:
Wie ist die Frage?
Zum Vergrößern anklicken....
Stimmt... Die Frage ist, wie bekomme ich das System ans laufen?! :-p

Erstmal cool und danke, dass Du auch am Samstag hier aktiv bist....

So, zu meiner Frage/Problem:
Habe jetzt z.B. eine Entp. an einem Call and Surf mit Dyn IP. auf Windows.

Wenn ich die 3CX auf feste IP stehen lasse, reg. sich der Trunk sofort.
Telefonie ein und ausgehend kein Problem.

Wenn ich die Netzwerkeinstellungen auf dynamisch stelle, kann ich den Anschluss gar nicht registrieren.
Es kommt: "Call or Registration to Name-Trunk has failed. sip:[email protected];transport=TCP replied: 403 Forbidden; from IP:217.0.148.5:5060"

Stelle ich wieder auf fest, sofort wieder Online.

Wie oben geschrieben soll das daran liegen, dass bei der dynamischen Konfig 3CX nicht die IP, sondern den FQDN mitsendet und das findet die Telekom doof. Für mich plausibel und macht ja durchaus Sinn. (Habe das aber noch nicht überprüft)

Daher brauche ich eine Lösung, wo im Template die aktuelle IP und nicht der FQDN mitgesendet wird, oder aber die feste IP via Script abgeglichen und ggf. geändert wird.
Aber diese müsste dann auch beim DNS-Dienst von 3CX aktualisiert werden.

Habe grad mal geschaut, was passiert, wenn die Anlage auf feste IP steht, sich dann die externe IP wechselt.
Eingehende und ausgehende Telefonie ist noch möglich. Der Anschluss bleibt registriert.

Zugriff von extern über den FQDN ist dann natürlich nicht möglich.
(Wollte damit nur sagen, dass der Telekom anscheinend egal ist, welche IP ich mitsende?!)

Wie lange das funktioniert, ob die Telekom nach x Stunden dann sagt, geht doch nicht, müsste man mal testen.

Habe das ganze System auch mal neu gestartet. Anschluss nach dem Reboot in Funktion mit der festen IP-Einstellung, wo jetzt aber die falsche IP hinterlegt ist.
 
krake79 schrieb:
Habe jetzt z.B. eine Entp. an einem Call and Surf mit Dyn IP. auf Windows.

Wenn ich die 3CX auf feste IP stehen lasse, reg. sich der Trunk sofort.
Telefonie ein und ausgehend kein Problem.

Wenn ich die Netzwerkeinstellungen auf dynamisch stelle, kann ich den Anschluss gar nicht registrieren.
Es kommt: "Call or Registration to Name-Trunk has failed. sip:[email protected];transport=TCP replied: 403 Forbidden; from IP:217.0.148.5:5060"
Zum Vergrößern anklicken....
Das Problem ist vmtl.: TCP. Bei diesem Produkt ist SIPS und SRTP aus und es wird UDP genutzt. Falls das im Trunk falsch eingestellt ist, dann gehe zu Admin / Erweitert / Parameter / Wählcode-Eigenschaften / <SIP-Trunk> und ändere den Parameter TRANSPORT_RESTRICTION entsprechend.
Falls der Tab nicht da ist, dann setze zuvor den 3CX Parameter DEVELOPMENT_DNTABLE_EXPOSE auf 1 und lade den Browser neu.

krake79 schrieb:
Daher brauche ich eine Lösung, wo im Template die aktuelle IP und nicht der FQDN mitgesendet wird
Zum Vergrößern anklicken....
Wir nutzen nach wie vor das ganz normale 3CX Template für solche SIP Trunks und das funktioniert bei Kunden eben auch mit dyn. IP - bis eben auf die Einstellung UDP.

krake79 schrieb:
Habe grad mal geschaut, was passiert, wenn die Anlage auf feste IP steht, sich dann die externe IP wechselt.
Eingehende und ausgehende Telefonie ist noch möglich. Der Anschluss bleibt registriert.

...
(Wollte damit nur sagen, dass der Telekom anscheinend egal ist, welche IP ich mitsende?!)
Zum Vergrößern anklicken....
Schau im REGISTER und INVITE was die 3CX ggb. dem Provider von sich gibt. Das ist entscheidend.

krake79 schrieb:
Zugriff von extern über den FQDN ist dann natürlich nicht möglich.
Zum Vergrößern anklicken....
Das liegt dann aber an den FQDN Einstellungen. Das ist das Thema der Aktualisierung der IP zum FQDN. Ja, das passiert wenn man einen nicht selbst verwaltenen FQDN verwendet. Dann ist man auf den Verwalter angewiesen. Wir haben das nirgends. Ich bin mir nicht einmal sicher, ob wir überhaupt noch eine kleine Testanlage mit 3CX FQDN bei uns haben. Daher kann ich das nicht nachstellen.
 
krake79 schrieb:
(Habe das aber noch nicht überprüft)
Zum Vergrößern anklicken....

So, habe ich grad mal gemacht.
Es ist also wirklich so:
Wenn ich die 3CX auf statische IP laufen lasse, dann registriert er sich erfolgreich mit:

Contact URI: sip:[email protected]:5060;transport=TCP;rinstance=484aa99d8eadd276

die 87.147.243.65 ist dabei die ALTE nicht mehr aktuelle dynamische IP!

Wenn ich die Anlage aif dyn. umstelle, dann sieht es so aus:

Contact URI: sip:[email protected]:5060;transport=TCP;rinstance=a00861542180077d
mit der Antwort:: Status-Line: SIP/2.0 403 Forbidden
 
krake79 schrieb:
Habe das ganze System auch mal neu gestartet. Anschluss nach dem Reboot in Funktion mit der festen IP-Einstellung, wo jetzt aber die falsche IP hinterlegt ist.
Zum Vergrößern anklicken....
Nutze die Macht, nutze ein Skript.
Wenn das schon eine Windows 3CX ist, dann z.B. so etwas hier:

3cx-powershell-xapi-ChangeNetwork.ps1

Code: 
$tcxurl = "mypbx.mydomain.de"   # needs port if not 443

$jsonauthbody = (@{
    Username="100"              # 3CX user, maybe email address
    Password="Super_Secret0815" # 3CX user password
    SecurityCode=""
} | ConvertTo-Json)

$LoginResponse = Invoke-RestMethod -Uri "https://$tcxurl/webclient/api/Login/GetAccessToken" -Body $jsonauthbody -Method POST -ContentType "application/json"

if( $LoginResponse.Status -ne "AuthSuccess" ) {
    Write-Host "abort: authentication not successful"
    exit -1
}

$headers = @{Authorization = "Bearer $($LoginResponse.Token.access_token)"}

$externalip = (Invoke-WebRequest "https://ifconfig.me/ip" -UseBasicParsing).Content.Trim()

$tcxnetworksettings = Invoke-RestMethod -uri "https://$tcxurl/xapi/v1/NetworkSettings" -headers $headers -Method GET -ContentType "application/json"

# switch to static ip
$patchdata = @{ PublicInterface = $tcxnetworksettings.PublicInterface; IpV6BindingEnabled = $tcxnetworksettings.IpV6BindingEnabled; StunDisabled = $true; PublicStaticIP = $externalip } | ConvertTo-Json
Invoke-RestMethod -uri "https://$tcxurl/xapi/v1/NetworkSettings" -headers $headers -Method PATCH -body $patchdata -ContentType "application/json"

# maybe restart some 3CX services or change back to dynamic ip?

Stichwort: powershell schnipsel

Das Skript darf gern weiter verfeinert werden, z.B. sicherheitshalber die Überprüfung ob die ext. IP Abfrage erfolgreich und plausibel war und ob überhaupt eine Anpassung der ext. 3CX IP erforderlich ist usw..
 
Zuletzt bearbeitet:
fxbastler schrieb:
Das Problem ist vmtl.: TCP. Bei diesem Produkt ist SIPS und SRTP aus und es wird UDP genutzt. Falls das im Trunk falsch eingestellt ist, dann gehe zu Admin / Erweitert / Parameter / Wählcode-Eigenschaften / <SIP-Trunk> und ändere den Parameter TRANSPORT_RESTRICTION entsprechend.
Falls der Tab nicht da ist, dann setze zuvor den 3CX Parameter DEVELOPMENT_DNTABLE_EXPOSE auf 1 und lade den Browser neu.
Zum Vergrößern anklicken....
Oh, das hast Du schneller geantwortet als ich den Trace machen konnte.
Ich glaube nicht, dass es am UDP oder TCP liegt.

Die Anlage muss einfach die IP übermitteln und nicht den FQDN!
 
krake79 schrieb:
Ich glaube nicht, dass es am UDP oder TCP liegt.

Die Anlage muss einfach die IP übermitteln und nicht den FQDN!
Zum Vergrößern anklicken....
Ich will dir nicht widersprechen. Wir benutzen grundlegend andere Umgebungen. Das ist nicht direkt vergleichbar und das kann und will ich jetzt auch nicht einfach mal eben tun.
Unser Problem bei 403 war offensichtlich immer die voreingestellte Verwendung von TCP für unverschlüsselte Verbindungen. Änderung auf UDP löst es.
 
fxbastler schrieb:
3cx-powershell-xapi-ChangeNetwork.ps1
Zum Vergrößern anklicken....
Ahh...
Cool, wenn ich das PS richtig lese,
Schaut es welche externe IP ich habe und trägt diese als feste IP ein.
Wenn ich diese nach der Zwangstrennung laufen lasse, sollte mein Problem ja vom Tisch sein.

Weißt Du ob 3CX den FQDN dann auch automatisch aktualisiert.

fxbastler schrieb:
Das liegt dann aber an den FQDN Einstellungen. Das ist das Thema der Aktualisierung der IP zum FQDN. Ja, das passiert wenn man einen nicht selbst verwaltenen FQDN verwendet. Dann ist man auf den Verwalter angewiesen. Wir haben das nirgends. Ich bin mir nicht einmal sicher, ob wir überhaupt noch eine kleine Testanlage mit 3CX FQDN bei uns haben. Daher kann ich das nicht nachstellen.
Zum Vergrößern anklicken....
Habe einfach immer die 3cx Domain genommen, weil dies mir von der Konfig mit den Zertifikaten einfacher erschien. Oder ist das nicht so wild...?
 
krake79 schrieb:
Weißt Du ob 3CX den FQDN dann auch automatisch aktualisiert.
Zum Vergrößern anklicken....
Ja, tut es, irgendwann. Ich weiss nur eben nicht wann.
Wir nutzen das nicht. Wir haben ausschließlich selbst verwaltete FQDN.

Ich habe gehört (sehr spekulativ), dass ein Wechsel von dyn. auf statisch (mit Korrektur) und danach wieder auf dynamisch so eine Aktualisierung bei 3CX beschleunig kann - aber ich weiß nicht ob es so ist. Mit dem Skript ist auch das automatisiert möglich. Es fehlen halt nur die Zeilen zum Zurückstellen auf dynamische IP.

krake79 schrieb:
Habe einfach immer die 3cx Domain genommen, weil dies mir von der Konfig mit den Zertifikaten einfacher erschien. Oder ist das nicht so wild...?
Zum Vergrößern anklicken....
Ja, das ist der Hintergrund: es ist einfach und liegt nahe.
3CX kümmert sich doch gern um deine Telefonanlage, deine Erreichbarkeit (per nicht firmeneigenen FQDN), deine Sicherheit (u.a. fremdes Ausstellen von Zertifikaten auf den firmenfremden FQDN), deinen E-Mail Versand (über den 3CX SMTP Server) usw. usf.. :D

Machen wir seit jeher bei allen unseren Anlagen selber. Wir sind alt genug. Wir können alleine spielen :)
 
fxbastler schrieb:
Ich will dir nicht widersprechen. Wir benutzen grundlegend andere Umgebungen. Das ist nicht direkt vergleichbar und das kann und will ich jetzt auch nicht einfach mal eben tun.
Unser Problem bei 403 war offensichtlich immer die voreingestellte Verwendung von TCP für unverschlüsselte Verbindungen. Änderung auf UDP löst es.
Zum Vergrößern anklicken....
Ich werde Dir nie wieder wiedersprechen!!! Habe auf den Trunk auf UDP geändert und alles ist gut!
Verstehe zwar nicht, warum die Telekom den FQDN bei TCP nicht mag, aber bei UDP akzektiert!

Egal - Dann ist das Thema ja vom Tisch! - VIELEN DANK!!!
 
  • Haha
  • Like
Reaktionen: bitn und fxbastler
fxbastler schrieb:
Ja, das ist der Hintergrund: es ist einfach und liegt nahe.
3CX kümmert sich doch gern um deine Telefonanlage, deine Erreichbarkeit (per nicht firmeneigenen FQDN), deine Sicherheit (u.a. fremdes Ausstellen von Zertifikaten auf den firmenfremden FQDN), deinen E-Mail Versand (über den 3CX SMTP Server) usw. usf.. :D

Machen wir seit jeher bei allen unseren Anlagen selber. Wir sind alt genug. Wir können alleine spielen :)
Zum Vergrößern anklicken....
Ja, das die meisten Kunden haben eh schon Wildcard Zertifikate! - Da werde ich das sicher auch so umsetzten.
Aber hier in der Testumgebung mit einer dynamischen IP, ist das mit der 3cx-Domain schon ein bissel einfacher...
:)

VIelen Dank nochmal.... Werde das das jetzt testen und kann so auch mit guten Gewissen alte Anlagen auch bei Kunden mit dem Call and Surf Anschlüssen nutzen.

Jetzt stehe ich zwar nur noch mit der übermittelten Nummer ein bisschen auf den Kriegsfuß, weil er nicht die Nummer nimmt, welche beim TN eingestellt ist, sondern einfach den ersten, welcher in den ausgehenden Regeln steht....
 
Um antworten zu können musst du eingeloggt sein.

Einstieg für Admins

Statistik des Forums

Themen
44.751
Beiträge
233.643
Mitglieder
78.493
Neuestes Mitglied
arming
3CX Logo Footer Copyright © Sitemap Datenschutz Impressum
Oben Unten