SIP-Trunk meldet sich nicht an

[relmek94]

Hallo, ich bedanke mich im Voraus für jeden Tipp. Danke.

Ich denke ich beschreibe zuerst die Konstellation:

- Neuste Version 3CX
- 2 WAN (Telekom / Unitymedia)
- Pfsense
- Fritzboxen

Die 3CX läuft virtualisiert. Die Pfsense ist entsprechend (korrekt) konfiguriert.
Die virutelle Maschine, wo die 3CX läuft geht über die Default Route via Unitymedia (WAN1) raus. (Wird für andere Dienste benötigt)
Mittels Firewallregeln wurden die benötigten SIP Ports mit Angabe von Gateway jedoch über Telekom (WAN2) rausgebracht. (Damit die 3CX über Telekom kommunizieren kann)
Funktioniert super, wenn eine Regel erstellt wird, das Quasi alles, über Telekom rausgeht was die 3CX Maschine schickt. (Soll aber nicht so sein, nur die entsprechenden Ports über Telekom)
Wenn ich nur die "pflicht" Ports 5060.5090 etc nehme, wird der Trunk nicht synchron.
Kurioserweise nur nicht über TCP. Stelle ich den SIP Trunk auf UDP um, kein Problem.
Ich hätte Ihn gern auch unter TCP synchron.
Weitere Möglichkeit den Trunk grün (Synchron) zu kriegen ist, den Portbereich (ausgehend!) 49600 - 49800 auch über die Telekom Route laufen zu lassen.
Warum werden wahllos ausgehende Ports genutzt, die in keinen Dokumentationen erwähnt werden? Klar es werden die von Außen freizugebenden angegeben, für das arbeiten mit Multiwan jedoch nicht ausreichend.
Wo könnten Fehler liegen?
Wer kann mir helfen?
Kann auch gerne weiter ins Detail gehen.

Fehler in der 3CX lauten dann z.B. wie folgt:

No transport is found for destination: <sipxxxxxxxxxxxxxx
oder
Registration at xxxxxxxxxx. Destination(siP: XXXXXXXXXXX@xxxxxxx:5060) is not reachable, DNS error resolving FQDN, or service is not available
oder
[CM506004]: STUN request to STUN server 51.38.45.26:3478 has timed out; used Transport: 0.0.0.0:5062/UDP
oder
There's another STUN server that resolves to the same IP: 54.37.20.144:3478/UNKNOWN_TRANSPORT fk=0 tgt=; ignored

Nochmals vielen Dank.

 

[bishop]

DNS Problem im eigenen Netz evtl?
Traceroute mal auf Destination(siP: XXXXXXXXXXX@xxxxxxx:5060) gemacht?

 

[relmek94]

@bishop

Der DNS auf der 3CX Maschine zeigt auf unseren lokalen DNS Server. Im lokalen DNS Server ist eine Weiterleitung an die Sense hinterlegt.

Weiterhin, wenn ich einen tracert auf "217.0.28.32:5060" (ohne Port) durchführe, sehe ich das er über den tracert über den "falschen" WAN weg, sprich WAN1 Unitymedia durchführt.

 

[bishop]

in der richtung würd ich mal suchen

 

[relmek94]

@bishop

Ich suche mich gefühlt seit Tagen dumm und dämlich. Ein Tipp wäre nicht übel, wie ich das hinbekommen könnte. Danke!

 

[bishop]

die vm läuft auf syno qnap esxi?
instanz hat eigene ip?
wenn nicht, kannst du der instanz eine eigene ip geben?
geht vlan?

 

[relmek94]

@bishop
Die vm läuft unter Hyper-V auf einem Windows Server.
Die Instanz hat eine eigene IP.
Wenn ich weiss wie ich in dem Fall mit VLAN agieren soll, sollte es kein Problem sein.
Ist es irgendwie zu begründen, warum der Trunk beim umschalten auf UDP "grün" wird? Oder warum er grün wird, wenn man ausgehende Ports im Bereich 49000 - 50000 über den Telekom Gateway lagt?

 

[bishop]

- Fritzboxen

was machen die boxen denn?

 

[relmek94]

@bishop
Die Telekomer FB hat direktes DSL, und hat Portforwarding auf die Sense. Die UM (Vodafone) Cable FB hat entsprechendes Forwarding auf eine darauf folgende freie FB und in dieser nochmals weitergereicht ebenfalls an die Sense. Das läuft soweit problemlos seit Jahren in mehreren Ausführungen. Die "3CX VM" so nenn ich sie mal, hat mehrere Dienste zu bedienen. Entsprechend müssen die SIP Ports über den Telekomer Strang raus, und andere Ports über den UM Strang. Es läuft in geschilderter konstellation alles bis auf dieses "problemchen". Danke

 

[mbehrens]

@bishop

Der DNS auf der 3CX Maschine zeigt auf unseren lokalen DNS Server. Im lokalen DNS Server ist eine Weiterleitung an die Sense hinterlegt.

Weiterhin, wenn ich einen tracert auf "217.0.28.32:5060" (ohne Port) durchführe, sehe ich das er über den tracert über den "falschen" WAN weg, sprich WAN1 Unitymedia durchführt.

Bei den DNS Ausführungen fehlt der entscheidende Weg, den die pfSense dann geht. Das Windows tracert deutet darauf hin, dass ICMP immer Richtung WAN1 geht.

 

[mbehrens]

Hallo, ich bedanke mich im Voraus für jeden Tipp. Danke.

Ich denke ich beschreibe zuerst die Konstellation:

- Neuste Version 3CX
- 2 WAN (Telekom / Unitymedia)
- Pfsense
- Fritzboxen

Die 3CX läuft virtualisiert. Die Pfsense ist entsprechend (korrekt) konfiguriert.
Die virutelle Maschine, wo die 3CX läuft geht über die Default Route via Unitymedia (WAN1) raus. (Wird für andere Dienste benötigt)
Mittels Firewallregeln wurden die benötigten SIP Ports mit Angabe von Gateway jedoch über Telekom (WAN2) rausgebracht. (Damit die 3CX über Telekom kommunizieren kann)
Funktioniert super, wenn eine Regel erstellt wird, das Quasi alles, über Telekom rausgeht was die 3CX Maschine schickt. (Soll aber nicht so sein, nur die entsprechenden Ports über Telekom)
Wenn ich nur die "pflicht" Ports 5060.5090 etc nehme, wird der Trunk nicht synchron.
Kurioserweise nur nicht über TCP. Stelle ich den SIP Trunk auf UDP um, kein Problem.
Ich hätte Ihn gern auch unter TCP synchron.
Weitere Möglichkeit den Trunk grün (Synchron) zu kriegen ist, den Portbereich (ausgehend!) 49600 - 49800 auch über die Telekom Route laufen zu lassen.
Warum werden wahllos ausgehende Ports genutzt, die in keinen Dokumentationen erwähnt werden? Klar es werden die von Außen freizugebenden angegeben, für das arbeiten mit Multiwan jedoch nicht ausreichend.
Wo könnten Fehler liegen?
Wer kann mir helfen?
Kann auch gerne weiter ins Detail gehen.

Fehler in der 3CX lauten dann z.B. wie folgt:

No transport is found for destination: <sipxxxxxxxxxxxxxx
oder
Registration at xxxxxxxxxx. Destination(siP: XXXXXXXXXXX@xxxxxxx:5060) is not reachable, DNS error resolving FQDN, or service is not available
oder
[CM506004]: STUN request to STUN server 51.38.45.26:3478 has timed out; used Transport: 0.0.0.0:5062/UDP
oder
There's another STUN server that resolves to the same IP: 54.37.20.144:3478/UNKNOWN_TRANSPORT fk=0 tgt=; ignored

Nochmals vielen Dank.

Die Konfiguration der pfSense ist für den Einsatz fehlerhaft. Das Policy Based Routing stimmt eindeutig nicht.

Warum dynamisch High Ports verwendet werden kann man in diversen Artikeln zur Netzwerkkommunikation nachlesen.

Nicht den DNS Server des SIP Anbieter zu nutzen, kann auch zu Problemen führen, wie man hier sieht (UM dann die Namen der SIP Server nicht auflösen).