I realise that it's unlikely anyone here has a definite "Check this box to resolve this" answer, but I'm struggling with this issue and I'm hoping that someone with more knowledge than me can give me some more insight or perhaps some terms and phrases to look for.
I'm investigating an odd issue with some embedded devices - long story short is that some of these devices (Possibly running a specific firmware version) aren't available through the NetScaler SSL VPN connection.
That's by the by, really, but during troubleshooting I noticed something that I'd like to know more about.
For testing, I set up a quick IIS server so that I could run WireShark and I get a subtly different traffic flow depending on whether I go through the VPN or not (Same machine, using Putty in RAW mode).
So, from WireShark on my IIS server (.117 below):
Without the VPN, from the Client I get the following traffic:
SYN
ACK
[Nothing happens, until I type "GET / HTTP/1.1" into Putty]
HTTP GET
ACK
FIN, ACK
With the VPN, from the Client I get:
SYN
FIN, ACK
[Nothing happens, until I type "GET / HTTP/1.1" into Putty]
HTTP GET
ACK
FIN, ACK
From my testing, I believe it's got to be the NetScaler that's sending that spurious FIN (I've tested from a machine in the DMZ, via the same Firewall etc and it doesn't have it) and I don't think it's out of the realms of possibility that an embedded device may not like it.
So, can anyone explain why NetScaler is doing this and how I can change it? I presume it's a TCP Profile configuration but I can't seem to figure it out.
I've attached two screenshots of the capture - both captures are using the same Client <-> Server and the same method (Putty). The only difference is whether I connect through the SSL VPN or not.
Update 1
In a moment of wondering, I changed the Web Server to listen on Port 81, instead of Port 80. With this configuration, the handshake is correct with no spurious FIN messages. This leads me to believe it's going to be something to do with the HTTP optimisation on NetScaler
0 Answers