Firewall-Check failed

[UKortkamp]

Hallo Community,
da dies mein erster Post hier im Forum ist...
Mein Name ist Uwe und ich bin seit etwas über 27 Jahre in der IT tätig. Hauptgebiete hierbei ist die MS-Welt: angefangen mit DOS/Win3.x bis zu allen aktuellen OS-Versionen. Natürlich gehören dazu auch ein Großteil des MS-Server Applikationen (SQL/Exchange usw.).

Seit vielen Jahren betreue ich auch zusätzlich noch Firewall und Mailserver des Hersteller Kerio:
"Kerio Connect / Kerio Control" (seit ~2 Jahren von GFI aufgekauft)

Das Thema VoIP TK-Anlage ist für mich recht neu (zumindest außerhalb dessen, was viele sicherlich als Home-Lösung "FritzBox" etc. selber nutzen).

Aktuell ist meine Firma in der Evaluierung die bestehende Alcatel TK Anlage gegen eine reine VoIP Anlage zu tauschen - und sind hierbei vor ~4 Wochen natürlich auch auf 3CX gestossen.

Für den ersten Test hatte ich mir ein DEBIAN-Iso geladen und unter ESXI 6.5 installiert. Das lief auch mit den ersten 15 "Testteilnehmern" und einem EASYBELL "Test-Trunk" recht gut.
Wichtig hier: Auch der 3CX Firewall Test funktionierte fehlerfrei.

Da wir gerne die Integration (speziell Kontakt Synchronisation) zu unserem OnPremise Exchange 2016 nutzen wollten (ohne den Exchange zu verbiegen) habe ich zwischenzeitlich einen Windows Server 2019 aufgesetzt und dort dann die 3CX "Windows Version" installiert - mit gleicher IP, wie vorher die DEBIAN Installation.

Beide Installationen (DEBIAN und Windows) sind LAN-seitig identisch eingerichtet:
- 1 LAN Karte, die zum internen LAN verbunden sind.
- Firewall Regel, die eingehende Pakete zur definierten offiziellen IP, an die jeweils lokale LAN-IP weitergeben (gem. den Portvorgaben durch 3CX)

Jetzt zum Problem:
in dieser (Windows-) Installation schlägt der Firewall-Check der 3CX an vielen Stellen fehl - und das obwohl die Firewall Konfiguration unverändert ist:
testing 3CX SIP Server... failed
testing port 5060... Mapping does not match 5060. Mapping is 51450
testing 3CX Media Server... failed
und viele andere Ports....

Fahre ich die Windows Instanz runter und starte DEBIAN - und dort dann den Firewall-Checker: Keine Probleme.

Ich mag also behaupten, das es an den Firewall Regeln/Freigaben/Port-Forwarding eigentlich nicht liegen kann. Zum Windows Test hatte ich die ausgehende Regel auch schon auf "Full Cone NAT" gesetzt (obwohl es für DEBIAN nicht notwendig war) - ebenfalls ohne Erfolg.

Die Windows Firewall ist für "Domänen-Netzwerk" abgeschaltet (und die Windows Installation IST Mitglied unseres AD).

Aktuell LIVE (zum Test) ist noch die DEBIAN Installation - daher kann ich noch nicht sagen, ob es mit der Windows Installation Probleme geben würde, oder nicht -- ich teste eben erst, bevor ich es für die Anwender freischalte ;-)

....und jetzt gehen mir langsam die Ideen aus - und hoffe das hier jemand ist, der noch welche hat!?

Besten Dank im Voraus und bleibt gesund.

 

[bitn]

Hallo,

mach mal testweise die Windows Firewall aus und teste erneut. Die Anfragen kommen ja von einem nicht Domänen Mitglied also von extern.

Beste Grüße

 

[UKortkamp]

Hallo Lars,
besten Dank für den schnelle TIP.
DAS weiß die Windows Firewall aber nicht, da sie ja nur 1 verbundenes LAN Interface hat - und das ist eben mit der Domäne verbunden -- und dafür ist die Firewall abgeschaltet (s.o.)

Abgesehen davon ist es beim Server 2019 nicht mehr möglich den Firewall-Dienst kplt. abzuschalten (jedenfalls nicht ohne tiefergehende Eingriffe in die Registry).

VG Uwe

 

[UKortkamp]

Ich denke den Fehler gefunden zuhaben...
Nachdem ich vorhin dann wieder die DEBIAN Installation aktiviert hatte, habe ich auch da den Firewall-Check nochmal laufen lassen: ALLES GRÜN

Nach etwas Gartenarbeit und einem Kaffee dann den Check nochmal angestoßen (weiterhin DEBIAN):nahezu identische Fehler, wie bei der Windows Installation. Erneuter Versuch weitere 10 Min: wieder alles grün.

Firewall Regeln sind gem. dieser Anleitung erstellt: https://www.3cx.com/docs/ports/

Also etwas debugging in der Firewall betrieben:
während des Firewall-Check werden ausgehend verstärkt Pakete zu "UDP 3478" gesendet (welche ich in vorgenannter Doku nicht sehe).
Dieser UDP Port war ausgehend zwar auch offen - aber über eine andere Regel und damit (in unserem Falle) mit einer anderen Quell-IP (x.x.x.82 statt x.x.x.88)

Nachdem vorgenannter Port auch in die "3CX Regeln" mit aufgenommen wurde -und damit via NAT mit der offiziellen IP der 3CX Anlage geschickt wurde- läuft auch der Firewall-Check aus dem Windows System heraus.

Warum es unter DEBIAN bei den meisten Tests trotzdem funktionierte und nur unter Windows nicht, bleibt weiterhin ein Rätsel - Fakt ist:Nun scheint es erstmal zu laufen.

Vorerst Danke an alle, die es heute evtl. trotzdem gelesen und sich Gedanken gemacht haben.

Gruß Uwe