Could someone explain why this site would fail via our firewalls, it works fine local and split tunnel. I would imagine it's to do with encryption levels as wireshark shows a few cypher spec changes during the handshake..
FYI.... SSL Proxy / decryption is switched off for this site and aplication is set to any and is classified as education/low risk
many thanks in advance...
This one is really weird, I can't even get an SSL exchange and it fails to download with both HTTP and HTTPS from this end. It looks like the server is giving back packets with the wrong flags? Not sure, packet dump shows weirdness and subsequent connection attempts show no response like the far end is filtering/limiting TCP SYN connections
client:1234 -> applicaa:433 - SYN - with sequence=0 sent
PA:5678 -> applicaa:443 - SYN (NAT'd outbound internet, with seq=0)
applicaa:443 -> PA:5678 - ACK (NAT'd inbound internet, with seq=large#, ack=large#) - why is this an ACK? Should be a SYN/ACK with seq=0, ack=1
applica:443 -> client:1234 - ACK (seq=1, ack=large#) - The PA seems to have changed the sequence number to "1" in reply to the client
client:1234 -> applicaa:443 - RST - client resets the connection with seq=1 because the sequence and acknowledgement numbers are wrong, PA drops the packet (doesn't send back to applicaa)
client again tries to initiate SYN connection to applicaa:443 from the same and new source ports... The new source port requests do not get any response. The same source port request gets SYN/ACK, this time with seq=0 but still has ack=large#. Client again resets the connection but the PA drops the reset packet. A 2 seconds later the applicaa server finally sends a SYN/ACK with a correct seq=0, ack=1, but the PA drops the incoming packet as the connection has been reset.
I'll have to do a bit more digging... this one is really weird. My only guess is that the applicaa.com server (or frontend proxy) is doing some sort of manipulation of the seq/ack values to identify bots. The combination of the malformed seq/ack, the PA changing the initial response sequence, and the PA dropping the reset packet to the back seq/ack, is breaking the connection. But not really sure... it is definitely weird.
I tested from home (not behind a PA) and see the same thing. Server responds with incorrect seq/ack values on initial connection (with an ACK, then a SYN/ACK), after multiple subsequent SYN retries you get a valid response. Takes a couple seconds of repeated retransmits, without the PA dropping the invalid responses it seems to work (but is slow initially).
Once you finally get a valid SYN/ACK and seq/ack values and establish a connection, subsequent new connections seem to immediately respond with valid values. So it seems to only be the initial connection to the server from a new IP. Smells like some sort of TCP SYN DOS protection in front of the server.
Click Accept as Solution to acknowledge that the answer to your question has been provided.
The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!
These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!
The LIVEcommunity thanks you for your participation!