ISA 2004 zeer trage SSL verbinding

[Verwijderd]

Ik heb op een bepaalde site een zeer trage connectie via ssl (www.vecozo.nl). Daar log ik in middels een verisign java popup die mij aan de hand van een certificaat valideert. Het ging op mijn werkplek super traag. Dikke str*nt was er niets bij. Na het aanpassen van de connectie timeout (60sec) en de aantal connectie per werkplek (1000000) is er wat leven in gekomen. Ik kan met de performance boost nu aardig uit de voeten op die website. Maar! Ik gebruik XP met sp2 en de cliënt zijn allemaal 2k sp4 met ie6 sp1. Je raad het al daar werkt het niet. Daar werkt niets meer na het inloggen op de website (dat gaat dan nog wel goed). Bovendien heeft ook nooit gewerkt op de nieuwe ISA 2004 server.

Inloggen met mijn account op een werkplek is ook geen oplossing, dus aan de rechten ligt het niet. Het betreft een HP server met W2k3 (patched) en ISA 2004 sp1. Ik heb ook al een werkplek voorzien van w2k3 sp1 en isa 2004 sp1 om te testen of het aan de configuratie/software ligt. Niets.

Ideetjes?

[Verwijderd]

Een troost: Je bent niet de enigste.

Ik ervaar hier het zelfde probleem. Windows2000 Terminal server omgeving. (SP4)
Ie 6.1 SP1)
Ook als ik geen gebruik maak van onze Proxy server (Webmarshal) en direct via NAT het internet op ga heb ik het zelfde probleem.

Op mijn eigen werkplek (Windows XP + alle Service packs en updates) is de site ook niet vooruit te branden.

Ik heb hier over diverse malen contact gehad met de helpdesk van vecozo. Het performance probleem is bij hun bekend. Er is laatst iets aan gedaan en toen ging het weer stukken beter. Op dit moment is het inderdaad weer traaaaag.

Ik zal dadelijk maar weer eens bellen met die knakkers.

[Rolfie]

Misschien heb je hier iets aan: Solving the Dreaded "500 Internal Server Error – The target principal name is incorrect" Error

[Verwijderd]

@martijntje

Een troost is het niet, met onze oude firewall (raptor) gaat het namelijk redelijk goed. Het moet echt iets in Isa/Webmarshal zijn. Draait dat ook onder w2003? Misschien id iets met de post van rolfi te maken. Hoewel dat artiel uitgaat van een client -> website ipv client -> proxy -> website zou het met ssl anders kunnen zijn.

@rolfi Ik ga het vanmiddag proberen.

[Verwijderd]

Verwijderd schreef op woensdag 29 juni 2005 @ 11:46:
@martijntje

Een troost is het niet, met onze oude firewall (raptor) gaat het namelijk redelijk goed. Het moet echt iets in Isa/Webmarshal zijn. Draait dat ook onder w2003? Misschien id iets met de post van rolfi te maken. Hoewel dat artiel uitgaat van een client -> website ipv client -> proxy -> website zou het met ssl anders kunnen zijn.

Ook direct achter NAT gaat het dus niet goed.

[Verwijderd]

Heb je al eens gekeken hoeveel open connecties hij maakt? (netstat -an)
Mogelijk kan/mag de client van de nat (demon) niet zoveel connectie opzetten.

Overigens de oplossing van rolfie werk niet.

[Verwijderd]

een netstat -an | find "195.18.123.148" geeft de volgende output:

code:

G:\>netstat -an | find "443"
  TCP    10.1.1.202:3704        195.18.123.148:443     ESTABLISHED

G:\>netstat -an | find "443"
  TCP    10.1.1.202:3704        195.18.123.148:443     ESTABLISHED

G:\>netstat -an | find "443"
  TCP    10.1.1.202:3704        195.18.123.148:443     ESTABLISHED
  TCP    10.1.1.202:3705        195.18.123.148:443     SYN_SENT

G:\>netstat -an | find "443"
  TCP    10.1.1.202:3704        195.18.123.148:443     CLOSE_WAIT

Dit doe ik terwijl ik door de site heen klik.

Zowel via NAT als via de proxy geeft ongeveer) bovenstaand resultaat.

Wat me opvalt is dat de connection state vrij snel veranderd van Established naar close_wait en vervolgens meteen weg is.

Bij andere (SSL) sites blijft de status veel langer op Established staan. Het kan zijn dat vecozo de connecties (te??) snel afkapt waardoor dingen in de soep lopen???

PS: Op dit moment gaat het browsen door de site vrij goed.

[relaxteb]

Hoi, hier een reactie van een Vecozo medewerker.

Als je problemen met onze site hebt, probeer dan eerst eens met een pc direct aan het internet en kijk hoe dat werkt.
Wij krijgen vaak heel veel vragen over problemen met verbindingen via citrix omgevingen en door firewalls heen etc.
9 van de 10 keer draait het er uiteindelijk op uit dat er een probleem bij de klant is.

Aangezien wij met zoveel verschillende klanten te maken hebben kunnen wij onmogelijk allerlei omgevingen na bouwen om het zelf te testen.

<edit >
nog even over de traagheid : wij groeien als kool, dus het is moeilijk de infrastructuur bij te houden in verhouding tot onze groei. Traagheid treedt vooral op aan het einde/begin van de maand. Dan worden de meeste declaraties verstuurd. Even voor het beeld : gemiddeld hebben wij per week nu 10 miljoen verzoeken op onze site ter controle van het verzekeringsrecht.
</edit>

[ Voor 30% gewijzigd door relaxteb op 29-06-2005 14:55 ]

[relaxteb]

Verwijderd schreef op woensdag 29 juni 2005 @ 11:12:
Een troost: Je bent niet de enigste.

Ik ervaar hier het zelfde probleem. Windows2000 Terminal server omgeving. (SP4)
Ie 6.1 SP1)
Ook als ik geen gebruik maak van onze Proxy server (Webmarshal) en direct via NAT het internet op ga heb ik het zelfde probleem.

Op mijn eigen werkplek (Windows XP + alle Service packs en updates) is de site ook niet vooruit te branden.

Ik heb hier over diverse malen contact gehad met de helpdesk van vecozo. Het performance probleem is bij hun bekend. Er is laatst iets aan gedaan en toen ging het weer stukken beter. Op dit moment is het inderdaad weer traaaaag.

Ik zal dadelijk maar weer eens bellen met die knakkers.

Toevallig heb ik vandaag een telefoontje gehad van iemand die ook problemen had direct via nat. Het bleek dat ze van provider geswitched waren en dat de NAT time out te kort was waardoor de SSL verbinding niet goed kon worden opgezet. Misschien een tipje om daar naar te kijken ?

[Verwijderd]

hi relaxteb, leuk je hier te zien. Als je klanten hebt met isa 2004 zou ik graag weten hoe of die de configuratie hebben binnen de firewall

Verwijderd schreef op woensdag 29 juni 2005 @ 14:45:
een netstat -an | find "195.18.123.148" geeft de volgende output:

code:

G:\>netstat -an | find "443"
  TCP    10.1.1.202:3704        195.18.123.148:443     ESTABLISHED

G:\>netstat -an | find "443"
  TCP    10.1.1.202:3704        195.18.123.148:443     ESTABLISHED

G:\>netstat -an | find "443"
  TCP    10.1.1.202:3704        195.18.123.148:443     ESTABLISHED
  TCP    10.1.1.202:3705        195.18.123.148:443     SYN_SENT

G:\>netstat -an | find "443"
  TCP    10.1.1.202:3704        195.18.123.148:443     CLOSE_WAIT

Het lijkt hier meer op:

code:

TCP    192.168.0.144:3294     192.168.0.251:80       TIME_WAIT
TCP    192.168.0.144:3296     192.168.0.251:80       TIME_WAIT
TCP    192.168.0.144:3298     192.168.0.251:80       TIME_WAIT
TCP    192.168.0.144:3299     192.168.0.251:80       TIME_WAIT
TCP    192.168.0.144:3300     192.168.0.251:80       TIME_WAIT
TCP    192.168.0.144:3301     192.168.0.251:80       TIME_WAIT
TCP    192.168.0.144:3302     192.168.0.251:80       TIME_WAIT
TCP    192.168.0.144:3303     192.168.0.251:80       TIME_WAIT
TCP    192.168.0.144:3304     192.168.0.251:80       TIME_WAIT
TCP    192.168.0.144:3305     192.168.0.251:80       TIME_WAIT
TCP    192.168.0.144:3306     192.168.0.251:80       TIME_WAIT
TCP    192.168.0.144:3307     192.168.0.251:80       TIME_WAIT
TCP    192.168.0.144:3308     192.168.0.251:80       TIME_WAIT
TCP    192.168.0.144:3309     192.168.0.251:80       TIME_WAIT
TCP    192.168.0.144:3310     192.168.0.251:80       TIME_WAIT
TCP    192.168.0.144:3311     192.168.0.251:80       TIME_WAIT
TCP    192.168.0.144:3312     192.168.0.251:80       TIME_WAIT
TCP    192.168.0.144:3313     192.168.0.251:80       TIME_WAIT
TCP    192.168.0.144:3314     192.168.0.251:80       TIME_WAIT
TCP    192.168.0.144:3316     192.168.0.251:80       TIME_WAIT
TCP    192.168.0.144:3317     192.168.0.251:80       TIME_WAIT
TCP    192.168.0.144:3318     192.168.0.251:80       TIME_WAIT

Maar dan nog veel langer Ik denk voor ieder object op de site 1x plus nog wat niet afgekapt wordt door de 60sec timeout die ik ingesteld heb binnen ISA.

[ Voor 14% gewijzigd door Verwijderd op 29-06-2005 16:32 ]

[relaxteb]

Heb je nou nog het advies opgevolgd van mijn collega en eerst de oude internet verbinding geprobeerd ?

[ Voor 11% gewijzigd door relaxteb op 30-06-2005 10:47 ]

[Verwijderd]

relaxteb schreef op woensdag 29 juni 2005 @ 16:39:
Heb je nou nog het advies opgevolgd van mijn collega en eerst de oude internet verbinding geprobeerd ?

Jups, een nieuwe isa server op de oude lijn levert dezelfde traagheid op.

ps. Wil je mijn naam uit die txt halen, dat stel ik niet zo op prijs.bvd

[ Voor 13% gewijzigd door Verwijderd op 29-06-2005 17:27 ]

[Verwijderd]

kick