14
Keine Citrix-Connection durch IPSec-VPN
Hallo zusammen,
ich habe ein sehr seltsames Phänomen.
Folgende Umgebung:
zwei Standorte, mit jeweils 100Mbit/s symetrisch.
Standort 1 hat eine Sonicwall TZ500 (FW: 6.5.4.9-92n)
Standort 2 hat eine Fortigate 200F (FW: 7.0.2)
Dazwischen ist ein IPSec-Tunnel, an beiden Firewalls ist ein VPN-Interface eingerichtet.
Routing ist statisch eingerichtet, jeweils das komplette Subnetz des anderen, da OSPF zwischen den beiden nicht funktionierte und die Sonicwall BGP nicht unterstützt(Lizenztechnisch).
Verbindungen über den Tunnel funktionieren alle (HTTPS, HTTP, SMB, Ping, RDP) außer unsere Citrix-Farm über den Storefront.
Anmelden am Storefront funktioniert, Starten der Sitzung ebenfalls.
Lediglich die Anzeige bleibt am Client grau und es wird an den Citrix-Hosts kein User angemeldet.
Firewall wurde testweise auf alles Standort 1 zu alles Standort zwei zugelassen, ebenso umgekehrte Richtung.
Hat jemand so ein Verhalten schon einmal beobachten können?
MfG Stephan
ich habe ein sehr seltsames Phänomen.
Folgende Umgebung:
zwei Standorte, mit jeweils 100Mbit/s symetrisch.
Standort 1 hat eine Sonicwall TZ500 (FW: 6.5.4.9-92n)
Standort 2 hat eine Fortigate 200F (FW: 7.0.2)
Dazwischen ist ein IPSec-Tunnel, an beiden Firewalls ist ein VPN-Interface eingerichtet.
Routing ist statisch eingerichtet, jeweils das komplette Subnetz des anderen, da OSPF zwischen den beiden nicht funktionierte und die Sonicwall BGP nicht unterstützt(Lizenztechnisch).
Verbindungen über den Tunnel funktionieren alle (HTTPS, HTTP, SMB, Ping, RDP) außer unsere Citrix-Farm über den Storefront.
Anmelden am Storefront funktioniert, Starten der Sitzung ebenfalls.
Lediglich die Anzeige bleibt am Client grau und es wird an den Citrix-Hosts kein User angemeldet.
Firewall wurde testweise auf alles Standort 1 zu alles Standort zwei zugelassen, ebenso umgekehrte Richtung.
Hat jemand so ein Verhalten schon einmal beobachten können?
MfG Stephan
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 1618098186
Url: https://administrator.de/contentid/1618098186
Ausgedruckt am: 20.11.2024 um 03:11 Uhr
14 Kommentare
Neuester Kommentar
Nein, aber du kannst die üblichen Werkzeuge verwenden um der Sache auf den Grund zu gehen, also:
alle Firewalls loggen was dabei durchgelassen, abgelehnt oder verworfen wird.
oder
mit tcpdump beobachten bis wohin die nötigen Protokolle kommen
alle Firewalls loggen was dabei durchgelassen, abgelehnt oder verworfen wird.
oder
mit tcpdump beobachten bis wohin die nötigen Protokolle kommen
da OSPF zwischen den beiden nicht funktionierte
Das ist auch logisch das das nicht geht denn OSPF nutzt Multicast zum Senden der Hellos was über einen VPN Tunnel bekanntlich nicht übertragen wird. Die Phase 2 definiert keine MC Adressen.Sollte man als Netzwerk Admin aber eigentlich auch wissen.
Wenn du aber auf deinen Sonicwall/Fortigate Pärchen einen GRE Tunnel einrichtest oder VTI Interfaces nutzt dann rennt es auch mit OSPF wunderbar und fehlerlos.
Guckst du hier:
Cisco, Mikrotik, pfSense VPN Standort Vernetzung mit dynamischem Routing
Gewusst wie...! 😉
Dein Citrix Problem ist sehr wahrscheinlich ein reines Firewall Regelproblem und hat nichts mit der Netzwerk Infrastruktur/VPN an sich zu tun. Das zeigt das ja sonst alles fehlerfrei rennt.
Vermutlich filtern also externe oder interne Firewalls den Citrix TCP/UDP Port oder Zieladressen irgendwo.
1
Hi,
hatte ich vergessen zu erwähnen.
Logs zeigen keine Auffälligkeiten.
traffic der Clients wird verarbeitet und weder etwas gedroppt noch denied.
Werde ich mir aber nochmals ansehen.
hatte ich vergessen zu erwähnen.
Logs zeigen keine Auffälligkeiten.
traffic der Clients wird verarbeitet und weder etwas gedroppt noch denied.
Werde ich mir aber nochmals ansehen.
Durch eine Firewall Regel geblockter Traffic ist auch nie eine "Auffälligkeit" da ja gewollt und taucht deshalb normalerweise auch nicht in Logs auf. 
Moin,
zunächst: welche Citrix-Version wird verwendet?
Fange dann am Storefront an:
ist die Windows-Firewall passend konfiguriert?
Nicht, dass du hier hängen bleibst. Schaue dir diesen Link einmal an.
Prüfe auch mal, ob im Log unter dem C:\inetpub-Folder des Storefront-Servers etwas zu finden ist.
Als nächstes: Greift ihr per Workspace App oder Browser auf die Session zu?
Danach: wie sieht es an den VPN-Gateways aus, sieht man, wie weit du kommst?
zunächst: welche Citrix-Version wird verwendet?
Fange dann am Storefront an:
ist die Windows-Firewall passend konfiguriert?
Nicht, dass du hier hängen bleibst. Schaue dir diesen Link einmal an.
Prüfe auch mal, ob im Log unter dem C:\inetpub-Folder des Storefront-Servers etwas zu finden ist.
Als nächstes: Greift ihr per Workspace App oder Browser auf die Session zu?
Danach: wie sieht es an den VPN-Gateways aus, sieht man, wie weit du kommst?
@aqui:
scheinbar wurde durch einen externen Dienstleister das ganze als GRE-Tunnel eingerichtet (Beide Seiten haben ein Interface mit einer 172....-Adresse), auf welches das OSPF eingerichtet wurde.
Das klappte so Semi, da die OSPF-Verbindung immer wieder unterbrach.
Aber das dürfte eigentlich egal sein, da das ganze als statisches routing eingerichtet ist.
Beide Firewalls haben in beide Richtungen eine Allow-All Regel und auch keine Security-Features aktiv.
@hem-pie:
wir sind in der Umstellung von einer alten Firewall zur Fortigate.
Über die alte VPN funktioniert alles, daher gehe ich davon aus, dass Storefront und Citrix richtig funktionieren.
Auf der alten Firewall gibt es auch keine "seltsamen routen" welche Citrix verschlucken würden.
Wir verwenden Igel mit OSv10 und Windows 10 mit Citrix Workspace. Aber auch der Zugriff über Web funktioniert bis zu dem Punkt wo ein neuer Tab mit der Sitzung gestartet wird. Ab da schwarzer Bildschirm.
Die Fortigate meldet dass der Triffic weiter gegeben wurde und auch Wireshark auf dem Session-Host zeigt den Traffic an, gleiche Packete wie an dem Client.
Wir werden es jetzt an den Support von Fortigate weiter geben, evtl. haben die eine Idee, was es sein kann oder können mit uns zumindest durch die Logs gehen.
Die Sonicwall ist denke ich nicht das Problem, da nur die Fortigate als Änderung im Netzwerk ist.
Danke aber für die hilfreichen Tips.
scheinbar wurde durch einen externen Dienstleister das ganze als GRE-Tunnel eingerichtet (Beide Seiten haben ein Interface mit einer 172....-Adresse), auf welches das OSPF eingerichtet wurde.
Das klappte so Semi, da die OSPF-Verbindung immer wieder unterbrach.
Aber das dürfte eigentlich egal sein, da das ganze als statisches routing eingerichtet ist.
Beide Firewalls haben in beide Richtungen eine Allow-All Regel und auch keine Security-Features aktiv.
@hem-pie:
wir sind in der Umstellung von einer alten Firewall zur Fortigate.
Über die alte VPN funktioniert alles, daher gehe ich davon aus, dass Storefront und Citrix richtig funktionieren.
Auf der alten Firewall gibt es auch keine "seltsamen routen" welche Citrix verschlucken würden.
Wir verwenden Igel mit OSv10 und Windows 10 mit Citrix Workspace. Aber auch der Zugriff über Web funktioniert bis zu dem Punkt wo ein neuer Tab mit der Sitzung gestartet wird. Ab da schwarzer Bildschirm.
Die Fortigate meldet dass der Triffic weiter gegeben wurde und auch Wireshark auf dem Session-Host zeigt den Traffic an, gleiche Packete wie an dem Client.
Wir werden es jetzt an den Support von Fortigate weiter geben, evtl. haben die eine Idee, was es sein kann oder können mit uns zumindest durch die Logs gehen.
Die Sonicwall ist denke ich nicht das Problem, da nur die Fortigate als Änderung im Netzwerk ist.
Danke aber für die hilfreichen Tips.
@aqui:
Sorry, die Fortigate hat eine explizite Deny-All Regel.
In den Logs dieser Regel trauchen nur die gewollten Blocks auf.
Seitens Sonicwall wurden an den Regeln nichts verändert und beide Interfaces sind der Zone VPN zugeiwesen.
Sorry, die Fortigate hat eine explizite Deny-All Regel.
In den Logs dieser Regel trauchen nur die gewollten Blocks auf.
Seitens Sonicwall wurden an den Regeln nichts verändert und beide Interfaces sind der Zone VPN zugeiwesen.
Sorry, die Fortigate hat eine explizite Deny-All Regel.
ALLE Firewalls haben diese Logik denn es ist weltweiter Standard bei Firewalls ! (Verbiete alles was nicht explizit erlaubt ist). 😉und beide Interfaces sind der Zone VPN zugeiwesen.
Solange keiner hier die Konfig dieser Zone kennt ist diese Info nichtssagend...1Sorry, die Fortigate hat eine explizite Deny-All Regel.
ALLE Firewalls haben diese Logik denn es ist weltweiter Standard bei Firewalls ! (Verbiete alles was nicht explizit erlaubt ist). 😉 Mikrotik muss manuell konfiguriert werden.und beide Interfaces sind der Zone VPN zugeiwesen.
Solange keiner hier die Konfig dieser Zone kennt ist diese Info nichtssagend...Dient in diesem Fall lediglich dem zuweisen von Firewall-Regeln.
Werden es aber wie gesagt an Fortigate weiter geben.
Alle stimmt so nicht face-wink Mikrotik muss manuell konfiguriert werden.
Mikrotik ist bekanntlich primär per se ein Router und keine Firewall ! Router arbeiten, wie der Netzwerk Admin weiß, generell IMMER nach einer Blacklist Logik und nicht nach einer Whitelist Logik wie Firewalls. Noch viel lernen du noch musst... würde Meister Yoda da sagen... 😉 face-wink Mikrotik muss manuell konfiguriert werden.2
das wusste ich jetzt noch nicht.
Hab Mikrotik nur von Kollegen mitbekommen.
Aber danke für die Info.
Sobald ich Info von Fortigate habe melde ich mich wieder und bereichte.
Hab Mikrotik nur von Kollegen mitbekommen.
Aber danke für die Info.
Sobald ich Info von Fortigate habe melde ich mich wieder und bereichte.
@aqui hatte alles korrekt konfiguriert
Nur nutzt unser Internetanbieter (MK Netzdienste) eine um MTU von 1492.
Die Fortigate nutzte aber 1500, Sonicwall 1492.
Wurde leider vor meiner Zeit in der Firma eingerichtet, daher hatte ich hierzu keine Infos.
Wurde dann mit dem Support angepasst, Anpassung nur per CLI auf dem WAN-Interface möglich.
Anpassung der MTU hat funktioniert.
Dann ging OSPF auch sofort und läuft stabil.
Citrix funktionierte auch sofort auf Anhieb.
Damit kann ich beruhigt in die Feiertage starten.
Grüße
Nur nutzt unser Internetanbieter (MK Netzdienste) eine um MTU von 1492.
Die Fortigate nutzte aber 1500, Sonicwall 1492.
Wurde leider vor meiner Zeit in der Firma eingerichtet, daher hatte ich hierzu keine Infos.
Wurde dann mit dem Support angepasst, Anpassung nur per CLI auf dem WAN-Interface möglich.
Anpassung der MTU hat funktioniert.
Dann ging OSPF auch sofort und läuft stabil.
Citrix funktionierte auch sofort auf Anhieb.
Damit kann ich beruhigt in die Feiertage starten.
Grüße
."Anpassung der MTU hat funktioniert. Dann ging OSPF auch sofort und läuft stabil."
Siehe auch:
https://ine.com/blog/2011-03-30-ospf-and-mtu-mismatch
Cisco, Mikrotik, pfSense VPN Standort Vernetzung mit dynamischem Routing
Siehe auch:
https://ine.com/blog/2011-03-30-ospf-and-mtu-mismatch
Cisco, Mikrotik, pfSense VPN Standort Vernetzung mit dynamischem Routing
Danke für die Info, dass hatte @aqui schon verlinkt.
Falsche mtu bezüglich ospf hatten wir auch beobachtet, daher dann mit static routing getestet.
Weiter oben hatte ich geschrieben, dass wir static routing genutzt haben.
Und dort citrix nicht ging.
Da citrix dann ging, haben wir dann auch ospf nochmal getestet.
Aber danke für den ersten link.
Falsche mtu bezüglich ospf hatten wir auch beobachtet, daher dann mit static routing getestet.
Weiter oben hatte ich geschrieben, dass wir static routing genutzt haben.
Und dort citrix nicht ging.
Da citrix dann ging, haben wir dann auch ospf nochmal getestet.
Aber danke für den ersten link.
