Allgemeine Frage zu Diensten und Regel Freigabe für Telekom pbx 2.0 Telefonie

Hallo,

Jetzt meine Frage. Wie bekomme ich raus, woran die Verbindung scheitert? -- erzeuge eine "deny"-regel, welch auch loggt. Bei der Standard-deny-regel ist das logging nicht aktiv. Dann sieht man auch, was verweigrt wird.

Wie behandelt die XGS Anfragen von Diensten die nicht definiert sind? -- "Any" beinhaltet auch nicht definierte Services

Aktuell ist die Default Network Policy: LAN beliebiger Host --> beliebiger Dienst --> WAN beliebiger Host  -- und trotzdem geht Webex nicht ...?

... das könnte an "Standardregeln wurden im Zuge der Ersteinrichtung angelegt" liegen. Dabei wird meist auch der WebFilter/Virenscanner und evtl. sogar SSL-Interception aktiviert. Da wird sich WebEx dran aufhängen. Baue manuell eine eigene "LAN beliebiger Host --> beliebiger Dienst --> WAN beliebiger Host" Regel ohne weitere aktivierte Features und platziere diese ganz oben.  (Wenn das dann geht, gibt es schöne lange Listen mit betroffenen IP's, welche eingepflegt werden müssen)

Hallo Dirk, danke für deine Antwort. 

Ich habe mal eine entsprechende Regel mit NAT Verknüpfung angelegt

die andere Standardregel habe ich deaktiviert.

Immer noch keine Verbindung.

Ich verstehe nur nicht, dass alle Dienste durchgehen, nur Telefonieserver nicht. Könnte das anhand der Konfiguraitonsliste (siehe oben Antwort bei Raphael) eine Rolle spielen?

Die Deny Regel die du meintest verstehe ich nicht so ganz. Eine Regel die erstmal alles blockt?

Gruß

Ok, danke für die Hilfestellung. 

Kurz nochmal zum Aufbau des Netzwerkes.

Fritzbox (Exposed Host auf IP der XGS) sowie statische Route ins Netz der XGS) --> XGS --> Netzwerk
Sollte so passen?

Ich habe das mit der Regel (Deny) entsprechend so umgesetzt

und stelle folgende Meldungen in der Log fest.

Nicht wundern, ich habe dem Client mal die 192.168.1.12 gegeben.

Ausschließlich die 137 Logs, Client frisch gestartet und den PBX 2.0 Client geöffnet. Telefondienst meldet, nicht erreichbar / nicht verbunden.

Es findet überhaupt keine weitere Protokollierung statt bezüglich des Versuchs. Es sei denn diese 137 Port Anfragen werden dadurch erzeugt.  Nichts von der Alles Blockieren Regel zu sehen. Liegt es vielleicht doch am Netzwerkaufbau? 

Danke nochmal für eure Hilfe.

Edit: zur Vollständigkeit:

Netzwerk:

Die Fritzbox hat die 192.168.178.1

Exposed Host auf 192.168.178.54

Satische Route: Netzwerk 192.168.1.0 Subnetz 255.255.255.0 Gateway 1921.68.1.54

Port 137 an eine Broadcast-IP x.x.x.255 ist nur ein billiger Versuch via NetBios-name-service einen Namen zu erfragen oder bekanntzugeben. Ist bei Windows-kisten normal. 

"Liegt es vielleicht doch am Netzwerkaufbau?" 
... Internet -- FritzBox -- Sophos -- LAN ... ist jetzt nicht wirklich komplex.
Die FB braucht eigentlich keine Route. Die Firewall maskiert ausgehendes und "eingehendes" verwendet den "exposed Host"

Ok, mir gehen da jetzt die weiteren Ideen aus :-(

Fakt ist, sobald ich die Sophos rausnehme, funktioniert die Verbindung sofort.

Sonst eine Idee, wie ich dahinter komme? 

SSL ist nicht aktiv (hinter Firewall & NAT) 

Bei Deine Konstellation und wenn Webex-Telefonie nichts anderes als SIP ist, dann kann es zur Hauptsache zwei gründe geben, warum hinter der Sophos nichts funktionert (Zitat):

1.) Über SIP meldet sich das VoIP-Endgerät beim SIP-Server an (REGISTER). Hierbei teilt es dem Server mit, unter welcher IP-Adresse und welchem Port es Anrufanfragen entgegennimmt. Hinter einer NAT-Firewall hat das allerdings eine private IP-Adresse, die von außen nicht erreichbar ist. Die öffentliche Adresse kennt das Endgerät im Allgemeinen nicht.

2.) Über SIP/SDP wird ein Telefongespräch ausgehandelt. Die eigentlichen Sprachdaten fließen jedoch via RTP über komplett andere Ports. Welche Ports das genau sind, entscheidet das VoIP-Endgerät und teilt sie der Gegenstelle beim Gesprächsaufbau mit. Also versucht die Gegenstelle, den RTP-Strom an den spezifizierten Port zu schicken. Dieser wird allerdings von der Sophos geschlossen, weil sie nichts von SIP und VoIP versteht (anders als die Fritte).

In beiden Fällen kommt es zu Schwierigkeiten, da im Protokoll auf der Anwendungsebene IP- und Port-Informationen geschickt werden. Eine normale Layer-3-Firewall kennt aber nur die Protokollebene und die darin enthaltenen IP- und Port-Informationen.

Helfen könnte die Nutzung eines Stun-Servers (Simple Traversal of UDP Through NATs, RFC3489) mit einem solchen besteht die Möglichkeit, mit dem hinter einem NAT-Router sitzenden SIP-Client die Netzwerkkonfiguration herauszufinden. Hierbei sendet das Endgerät eine Nachricht an einen außerhalb des LAN befindlichen STUN-Server. Dieser schickt dann ein Paket zurück, das Absenderadresse und -port enthält, also die tatsächlichen Informationen, die vom NAT-Router dort eingetragen wurden. Durch die Verbindung zum STUN-Server ist automatisch ein Port im NAT geöffnet, der zum Endgerät weitergeleitet wird.

Also schau einmal nach, ob bei Deinem Webexclient die Möglichkeit besteht, einen Stun-Server einzutragen. Übrigens - der von der Telekom (stun.t-online.de:3478) funktioniert ganz gut.

Zum Glück kann die Sophos Firewall mit SIP + RTP umgehen. Für solche Protokolle gibt es verschiedene "Helper" (wie z.B. auch für FTP)
"The firewall provides comprehensive traffic processing from layer 2 to layer 7"
Wenn bei einem SIP-Telefonat RTP nicht verbunden wird, kann eine (oder beide) Seiten nichts hören. Die Grundaushandlung HTTPS/SIP/Anwendungsspezifische Ports funktioniert dann aber Normalerweise.
WebEx ist (im Cisco-Umfeld) so etwas wie Skype/Telegram/MS-Teams. Da spielt RTP eine untergeordnete oder keine Rolle.
Kann natürlich sein, dass die Telekom da was verbogen hat.

Und wie gesagt, in meiner Umgebung (nahezu die Beschriebene) läuft WebEx problemlos.

Der einzige Unterschied ... keine Route in der FB meine FW mach SNAT nach "aussen". Sollte nach dem Wizzard aber auch so sein.
Frage: wird die Route auf der FB deaktiviert, funktioniert der Internetzugriff weiterhin ... oder?

Ok, mit Webex kenne ich mich nicht so wirklich aus, eher überhaupt nicht Aber z.B. 3CX verlangt das Absschalten des SIP Application Layer Gateways -warum auch immer- und prüft dies auch beim FW-Test.

Hi, also die Route hatte ich im Zuge des Troubleshootings hinterlegt. Die Internetverbindung ging auch ohne das ist korrekt.

Vielleicht sollte ich parallel mal ein Ticket bei der Telekom eröffnen und das Problem beschreiben. Ich nehme an, auch eure Ideen sind ausgeschöpft?

Edit: ich hatte ausversehen auf "verify Answer" hier angegeben ;-)

Zu deiner Antwort:

SSL ist nicht aktiv (hinter Firewall & NAT) 

Wie genau muss ich das verstehen? Was muss ich ändern?

Ist die Frage noch offen?

Wenn es auch ohne die Route auf der FB funktioniert, muss auch das NAT/Maskieren an der Sophos OK sein.

Die Karteikarte zum Konfigurieren/abschalten von SSL-Decryption befindet die hinter denen von Firewall & NAT. Testweise mal komplett deaktivieren, falls es aktiv ist.

... und ja, ich habe keine Ideen mehr. 

Ist die Frage noch offen?

Wenn es auch ohne die Route auf der FB funktioniert, muss auch das NAT/Maskieren an der Sophos OK sein.

Die Karteikarte zum Konfigurieren/abschalten von SSL-Decryption befindet die hinter denen von Firewall & NAT. Testweise mal komplett deaktivieren, falls es aktiv ist.

... und ja, ich habe keine Ideen mehr.