V20 nicht angemeldet / verfügbar funktioniert nur eingeschränkt

[bitn2]

Ich schau mir mal die Firewall-Logs an, wohin er nach Hause telefonieren will, nur um grün zu werden.
Meine Hoffnung war, als Du Proxy in den Ring geworfen hast, daß das bei Dir schon eine bekannte Sache ist...

Ja das ist bekannt, deswegen den Proxy abschalten. Der zerhackt dir die nötigen Daten für die 3CX. Nach Hause telefonieren tut da nichts. Es dürfen die Pakete nur nicht verändert werden durch einen Proxy.

 

[Ruddimaster]

Proxy abschalten

für die ganze Company? Das ganze LAN?

 

[bitn2]

für die ganze Company? Das ganze LAN?

Für die 3CX. Also alle Zugriffe auf die 3CX müssen am Proxy vorbei.

 

[Ruddimaster]

Ist... Ich mal was

 

[bitn2]

Ist... Ich mal was

Bitte?

 

[Ruddimaster]

 

[Ruddimaster]

Also 3CX ist in einer DMZ. Any nach Draussen... X Ports rein.
Die Clients (LAN) haben Any zur 3CX. Aber nur über den Proxy kommen sie ins WWW

 

[bitn2]

Jupp, wie gesagt. Die 3CX als Ausnahme setzen das die daran vorbei darf. Sonst wird das nichts.

 

[bitn2]

Sobald du im Browser irgendwas eingibst, geht es ja über den Proxy.... Split DNS korrekt eingerichtet?

 

[Ruddimaster]

Split DNS korrekt eingerichtet?

Jein, brauche ich nicht, da die PBX eine offizielle IP hat (Kein NAT). Es wird auch ein externer FQDN genutzt.

 

[bitn2]

Jein, brauche ich nicht, da die PBX eine offizielle IP hat (Kein NAT). Es wird auch ein externer FQDN genutzt.

Falsch, intern aus dem Netz muss der FQDN auf die interne IP auflösen. Tut er das?

 

[Ruddimaster]

Ich habe keine interne IP... in der DMZ sind offizielle, die ich auch intern nutze...

 

[Ruddimaster]

So... die Logs melden mir, daß direkt nach dem Anmelden Akamai-Seiten aufgerufen werden..

23.52.181.141 ... dann 2.18.97.227​

vielleicht bin ich da auf dem Holzweg... werde aber mal sequenziell Bereiche freigeben...​

 

[bitn2]

Dein Problem ist das du keine interne IP hast, was auch immer das für einen Sinn macht. Somit geht alles durch den Proxy was du an die 3CX schickst.

 

[Ruddimaster]

Da gebe ich Dir recht.
Aber ich habe da keine Alternative. Ich stell den Eimer nicht in das LAN, wo es Zugriff von Aussen gibt. Wenn die PBX kompromitiert wurde, habe ich das im internen Netz.
Dafür gibt es ja eine DMZ.
Wohlbemerkt, alles was in die DMZ geht, läuft nicht über den Proxy. Das wurde der Einfachheit halber in dem Bild nicht berücksichtigt.
Ich denke wenn ich mit den Freischaltungen nicht weiter komme, daß ich einen Case eröffne...
Aber vielen Dank für Deine Mühen und schnelle Reaktion!!!

 

[bitn2]

Ich stell den Eimer nicht in das LAN, wo es Zugriff von Aussen gibt. Wenn die PBX kompromitiert wurde, habe ich das im internen Netz.

Dann solltest du dich noch mal mit dem Thema DMZ auseinandersetzen. Ich glaube da fehlt es noch an Verständnis.

Ich denke wenn ich mit den Freischaltungen nicht weiter komme, daß ich einen Case eröffne...
Aber vielen Dank für Deine Mühen und schnelle Reaktion!!!

Versuch mal im Proxy alles an deinen FQDN raus zu nehmen, evtl hilft das.

Kein Problem..

 

[fxbastler]

Aber ich habe da keine Alternative. Ich stell den Eimer nicht in das LAN, wo es Zugriff von Aussen gibt. Wenn die PBX kompromitiert wurde, habe ich das im internen Netz.

Exakt unser Nutzungsszenario in quasi allen unseren 3CX Installationen: separate DMZ ausschließlich für Telefonie, exakt aus diesem Grund. Entweder durchgehend durch separate Switche oder notfalls strikt per VLAN an den Switchen (nicht den Telefonen und ohne hybride Ports an den Switchen) getrennt.

Auch wenn die Telefonie und insbes. die 3CX tlw. von außen an der FW über eine eigene öff. IP angesprochen wird (dann halt kein Reverse Proxy für 443 TCP wie sonst): die komplette DMZ der Telefonie (3CX, alle int. Endgeräte außer die Smartphone und Computer Apps) nutzt eine RFC1918 Addresse und Split DNS. So steht es aktuell in der 3CX Dokumentation in den Installationsvoraussetzungen und das funktioniert, seit Jahren, mit v18 und v20.