ISA, NLB en ASP web app

[siepeltjuh]

Een nieuwe webapplicaties die we sinds kort gebruiken geeft in sommige gevallen wat problemen en ik kom er niet uit.

Situatie:


Probleem:
Vanuit het intranet werkt alles 100%.
Vanuit het internet (dus via ISA) werkt in ieder geval Google Chrome niet. Met Firefox en Safari zijn een enkel geval bekend. Internet Explorer werkt altijd.
Zodra je in een dropdownbox (of elk ander form element met postback) iets invult vergeet hij deze keuze.

Analyse:
De response header van Chrome (na een postback) is een 302 waar de location gelijk is aan het orgineel met de toevoeging: &AuthResend1908BC2350124b5095AB75012FA40511 (dit nummer varieert)

IE post request bevat:
Referer pagina.aspx&AuthResend1908BC2350124b5095AB75012FA405BA

Chrome post request bevat:
Referer pagina.aspx

Vermoedelijk zit daar dus het probleem, maar natuurlijk nu de hamvraag, waarom mist Google Chrome deze authresend?

Is er iets in de ISA, NLB of webapplicatie dat hier controle over heeft?

Het gekke is dat het via het intranet wel gewoon werkt.

[ Voor 4% gewijzigd door siepeltjuh op 06-09-2011 19:32 ]

[siepeltjuh]

Helaas, het ligt niet aan de referer. Met Chrome 14 beta is het referer probleem verholpen maar het probleem blijft bestaan.
Aan de HTTP request kan ik 0,0 vinden wat de oorzaak zou zijn.

Opnieuw met Chrome inloggen via ISA, pas een selectie veld aan, -> response code 302
ik wacht enkele minuten en pas opnieuw een selectie veld aan -> respons code 200 en de keuze is onthouden. Elke volgende post request verandert daarentegen weer in een 302 response

Gelijktijdig geeft IE altijd een response 200.

Waardoor wordt de status 302 getriggert?

[alt-92]

Komt omdat je VIEWSTATE in je ASP.NET webforms applicatie per node gebonden is.

[Rolfie]

Hoe is je NLB geconfigureerd?

[Verwijderd]

Kijk even na hoe Session State staat ingesteld, wellicht wordt je tussen de verschillende requests van de ene node naar de andere node geslingerd.

[megamuch]

Ik ken ISA eigenlijk niet, maar ben redelijk bekent met NLB. Ik heb zo'n vermoeden dat die NLB slechts aan 1 kant van het cluster staat geconfigureerd. Waarschijnlijk intern, waarbij er op die NLB wordt bijgehouden op welke node je zit. Maar dat is gissen zonder meer info.

[siepeltjuh]

@alt-92
Hoe kan het intern dan wel weken? intern/extern beide verbinden met het cluster. Zolang de machinekey gelijk is zouden beide machines de viewstate kunnen gebruiken. En waarom werkt het met Internet Explorer dan wel zowel in als extern?

@KerberosX
Hoe kan het dan wel met een andere browser werken?

@Megamuch welke info zou je graag zien?

Zo dadelijk ga ik de NLB manager doorlichten en eens kijken hoe de afinity enz staan ingesteld. het enige verschil tussen in en extern is dat ISA er tussen zit. Zou het zo kunnen zijn dat ISA niet op een correcte manier naar het NLB cluster verwijst?

EDIT:
Oke, een aantal testjes later. Het probleem doet zich ook voor op het moment dat 1 van de twee nlb nodes uit het cluster is gehaald. (stopped)
Daarmee zou de affinity enz er al niet meer toe doen, maar voor de zekerheid:

[ Voor 19% gewijzigd door siepeltjuh op 13-09-2011 17:51 ]

[siepeltjuh]

Subtiel kickje, iemand nog een suggestie? Alles is nog een keer gecontroleerd, maar kan niet vinden waar het nu in zit.

[johnkeates]

Heb je Microsoft al gebeld?

[siepeltjuh]

Het is weer even geleden, maar wou toch even melden dat het opgelost is. Ook voor mensen die dit topic via de search vinden.

De daadwerkelijke oorzaak (401 melding van IIS naar ISA/FTMG) is nog niet opgelost, maar er is wel een oplossing waardoor clients er niets meer van merken:

KB artikel: FIX: POST requests to a web server that is running Forefront Threat Management Gateway 2010 may fail