8
Squid Reverse Proxy Login Form Problem
Hallo zusammen,
Umgebung ist ein PfSense CARP Cluster mit Squid Reverse Proxy.
Der Reverse Proxy wird zur Filterung des Exchange Zugriffes genutzt. Aktuell steht noch ein IP Adressen Netz zur Verfügung. In einigen Monaten wird sich das auf eine externe IP reduzieren.
Wir nutzen eine programmierte Kundenumgebung mit einem klassichen Forms Login die derzeit auf einer anderen IP mit NAT läuft.
Heute habe ich dieses System testweise über den Reverse Proxy der Exchange IP laufen lassen und der Login funktioniert nicht. Er springt quasi jedes mal auf die Loginmaske zurück.
In 2 Fällen funktioniert der Login genau 1 mal:
- Squid Service wird neu gestartet
- Local Cache wird gelöscht.
Es scheint also so zu sein, dass der Squid den Login cached und die Anfrage nicht an den Server weitergegeben wird.
Ich habe von diverse Optionen ausprobiert:
- Umgehung von Destinantion IP's
- Umgehung bei der Domain
- Cachen erst ab einer größeren Dateigröße
- Offlinemode
Hilft alles nichts.
Gebe ich temporär die Exchange OWA mal frei, funktioniert der Forms Login dort übrigens.
Hat jemand eine Idee was ich machen kann?
Lg
Theo
Umgebung ist ein PfSense CARP Cluster mit Squid Reverse Proxy.
Der Reverse Proxy wird zur Filterung des Exchange Zugriffes genutzt. Aktuell steht noch ein IP Adressen Netz zur Verfügung. In einigen Monaten wird sich das auf eine externe IP reduzieren.
Wir nutzen eine programmierte Kundenumgebung mit einem klassichen Forms Login die derzeit auf einer anderen IP mit NAT läuft.
Heute habe ich dieses System testweise über den Reverse Proxy der Exchange IP laufen lassen und der Login funktioniert nicht. Er springt quasi jedes mal auf die Loginmaske zurück.
In 2 Fällen funktioniert der Login genau 1 mal:
- Squid Service wird neu gestartet
- Local Cache wird gelöscht.
Es scheint also so zu sein, dass der Squid den Login cached und die Anfrage nicht an den Server weitergegeben wird.
Ich habe von diverse Optionen ausprobiert:
- Umgehung von Destinantion IP's
- Umgehung bei der Domain
- Cachen erst ab einer größeren Dateigröße
- Offlinemode
Hilft alles nichts.
Gebe ich temporär die Exchange OWA mal frei, funktioniert der Forms Login dort übrigens.
Hat jemand eine Idee was ich machen kann?
Lg
Theo
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 363987
Url: https://administrator.de/contentid/363987
Printed on: April 18, 2024 at 22:04 o'clock
8 Comments
Latest comment
POST-Anfragen (wie sie bei Login-Formularen verwendet werden) können nicht gecached werden. Es kann allerdings passieren, dass nach dem Login etwas per Weiterleitung geladen wird, was nicht gecached werden dürfte.
Das kann auch die Formularseite selbst betreffen, da hier möglicherweise ein Hidden-Field mit einer Session-ID verwendet wird.
Ob wirklich Caching stattfindet, kannst du entweder aus dem Squid-Log herausfinden (da steht dann "CACHE_HIT" dran) oder auch, wenn du mit den Developer-Tools verfolgst, was da passiert. In den Headern, die der Squid mitliefert, ist da normalerweise auch vermerkt, ob da etwas gecached wurde.
Optimalerweise sollte OWA selbst vernünftige Header mitsenden, die das Caching klar verbieten - falls das nicht funktioniert, solltest du mal testweise dem Squid per ACL das Caching sämtlicher Elemte des OWA verbieten (Stichwort: "cache deny all").
Zuletzt noch: Wird durchgängig HTTPS eingesetzt? Also wird der OWA selbst per HTTPS angefragt und der Squid reicht das einfach durch? Dann kann Caching eigentlich komplett ausgeschlossen werden, da Squid ja keine Inhalte mitlesen oder zwischenspeichern kann.
Das kann auch die Formularseite selbst betreffen, da hier möglicherweise ein Hidden-Field mit einer Session-ID verwendet wird.
Ob wirklich Caching stattfindet, kannst du entweder aus dem Squid-Log herausfinden (da steht dann "CACHE_HIT" dran) oder auch, wenn du mit den Developer-Tools verfolgst, was da passiert. In den Headern, die der Squid mitliefert, ist da normalerweise auch vermerkt, ob da etwas gecached wurde.
Optimalerweise sollte OWA selbst vernünftige Header mitsenden, die das Caching klar verbieten - falls das nicht funktioniert, solltest du mal testweise dem Squid per ACL das Caching sämtlicher Elemte des OWA verbieten (Stichwort: "cache deny all").
Zuletzt noch: Wird durchgängig HTTPS eingesetzt? Also wird der OWA selbst per HTTPS angefragt und der Squid reicht das einfach durch? Dann kann Caching eigentlich komplett ausgeschlossen werden, da Squid ja keine Inhalte mitlesen oder zwischenspeichern kann.
Hi Lord Gurke,
du hast mich da falsch Verstanden. Die OWA hab ich nur freigegeben um zu testen ob der Forms Login überhaupt über den Proxy funktioniert bzw. die unterschiedlichen Ausgaben zu prüfen.
Das Problem betrifft eine ASP.WEB Anwendung die für uns programmiert wurde.
Und ja, es wird durchgängig HTTPS verwendet. Der Aufruf ist zwar auch per HTTP möglich, wird aber auf dem IIS per Redirect rule auf HTTPS umgeleitet.
Aber unabhängig davon werde ich mich mal durch deine Anmerkungen wühlen. Danke dir erstmal!
lg
Theo
du hast mich da falsch Verstanden. Die OWA hab ich nur freigegeben um zu testen ob der Forms Login überhaupt über den Proxy funktioniert bzw. die unterschiedlichen Ausgaben zu prüfen.
Das Problem betrifft eine ASP.WEB Anwendung die für uns programmiert wurde.
Und ja, es wird durchgängig HTTPS verwendet. Der Aufruf ist zwar auch per HTTP möglich, wird aber auf dem IIS per Redirect rule auf HTTPS umgeleitet.
Aber unabhängig davon werde ich mich mal durch deine Anmerkungen wühlen. Danke dir erstmal!
lg
Theo
Also 2 unterschiede habe ich in den Devolment Tools:
Über den Proxy gibt es mit allen deaktivierten Cache EInstellungen die beiden EInträge:
X-Cache MISS from Gatewaysecurity
X-Cache-Lookup MISS from Gatewaysecurity:3128
Der Hauptunterschied nach dem löschen des Caches ist:
Set-Cookie .ASPXAUTH_ES_CS=674416C35A9595…CF2601EFC20; path=/; HttpOnly
Ab dem 2.Aufruf ist dieser Part nicht mehr Teil der der Antwortkopfzeilen.
Beim Exchange OWA überlebt der Set-Cookie den 2.Aufruf
Gibt es hier beim Proxy bzw. eventuell bei der ASP.Web Anwendung einen Header der dazu führt das der Cookie nicht beim 2. Aufruf verschwindet?
lg
Theo
Über den Proxy gibt es mit allen deaktivierten Cache EInstellungen die beiden EInträge:
X-Cache MISS from Gatewaysecurity
X-Cache-Lookup MISS from Gatewaysecurity:3128
Der Hauptunterschied nach dem löschen des Caches ist:
Set-Cookie .ASPXAUTH_ES_CS=674416C35A9595…CF2601EFC20; path=/; HttpOnly
Ab dem 2.Aufruf ist dieser Part nicht mehr Teil der der Antwortkopfzeilen.
Beim Exchange OWA überlebt der Set-Cookie den 2.Aufruf
Gibt es hier beim Proxy bzw. eventuell bei der ASP.Web Anwendung einen Header der dazu führt das der Cookie nicht beim 2. Aufruf verschwindet?
lg
Theo
Gibt es einen Bruch zwischen dem Browser und dem Server was das Protokoll angeht?
Also, dass z.B. der Browser per HTTPS zugreift, der interne Server aber nur per HTTP ohne Verschlüsselung angesprochen wird?
Dieses "httpOnly" in der Cookie-Zeile irritiert mich halt etwas...
Also, dass z.B. der Browser per HTTPS zugreift, der interne Server aber nur per HTTP ohne Verschlüsselung angesprochen wird?
Dieses "httpOnly" in der Cookie-Zeile irritiert mich halt etwas...
ich denke einen Bruch sollte es nicht geben.
Im Squid Reverse ist "Squid HTTPS Reverse Proxy angehakt" und dort das Zertifikat hinterlegt. Der SSL Proxy ist an einen localhost Port gebunden auf den per NAT weitergeleitet wird.
Dort über die Mappings dann zum IIS Server.
Das selbe Zertifikat ist auf dem IIS eingebunden.
Im Squid Reverse ist "Squid HTTPS Reverse Proxy angehakt" und dort das Zertifikat hinterlegt. Der SSL Proxy ist an einen localhost Port gebunden auf den per NAT weitergeleitet wird.
Dort über die Mappings dann zum IIS Server.
Das selbe Zertifikat ist auf dem IIS eingebunden.
Wird der IIS denn via HTTP vom Squid angesteuert oder auch per HTTPS?
Wenn das Protokoll zwischen dem Client und dem IIS nicht durchgängig identisch ist, wir die ASP-Anwendung da vielleicht von HTTP ausgehen und alle URLs und Cookies entsprechend für HTTP statt HTTPS anpassen.
Wenn das Protokoll zwischen dem Client und dem IIS nicht durchgängig identisch ist, wir die ASP-Anwendung da vielleicht von HTTP ausgehen und alle URLs und Cookies entsprechend für HTTP statt HTTPS anpassen.
Also ehrlich gesagt wüsste ich nicht wo das festgelegt wird. Eingerichtet sind beide Optionen.
Unter den Webserver Einträgen habe ich habe ich sowohl Port 80 als auch 443 eingerichtet. In den Mappings sind beide Server (HTTP,HTTPS) bei den passenden URIs ausgewählt.
Unter den Webserver Einträgen habe ich habe ich sowohl Port 80 als auch 443 eingerichtet. In den Mappings sind beide Server (HTTP,HTTPS) bei den passenden URIs ausgewählt.
Guten Morgen,
ich habe gerade die komplette HTTP Strecke aus dem Proxy genommen.
Mapping des URIs zeigt nur noch auf den HTTPS Webserver und der HTTP Server ist deaktiviert.
Und siehe da es geht.
Allerdings reicht es schon, dass der HTTP Webserver in der Konfig aktiv ist und NICHT ins Mapping für den URI eingebunden ist das es nicht mehr funktioniert.
Finde ich sehr seltsam.
Gibt es denn jetzt noch eine Möglichkeit HTTP auf HTTPS umzuleiten? Bis jetzt passierte das ja Serverseitig.
LG
Theo
ich habe gerade die komplette HTTP Strecke aus dem Proxy genommen.
Mapping des URIs zeigt nur noch auf den HTTPS Webserver und der HTTP Server ist deaktiviert.
Und siehe da es geht.
Allerdings reicht es schon, dass der HTTP Webserver in der Konfig aktiv ist und NICHT ins Mapping für den URI eingebunden ist das es nicht mehr funktioniert.
Finde ich sehr seltsam.
Gibt es denn jetzt noch eine Möglichkeit HTTP auf HTTPS umzuleiten? Bis jetzt passierte das ja Serverseitig.
LG
Theo
