Strange behaviour via Palo Alto Firewall.

[Mick_Ball]

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...

https://applicaa.com/

[Adrian_Jensen]

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.

[TomYoung]

Hi @Mick_Ball ,

In the decryption rule that excludes that site, do you have the same decryption profile applied?

Thanks,

Tom

[Adrian_Jensen]

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.

[Mick_Ball]

Hi Tom, for the purpose of this test I am using a Palo which has SSL Proxy turned off, that’s my usual second test after removing application default.

[Mick_Ball]

Hi Adrian, yes I had similar experience when added to domain split tunnel.. can’t see what the issue would any different from the server end as both connections were NATed….. I’m gonna do some further testing today….

[Mick_Ball]

FYI.

SSL Labs shows as below...

and Palo is dropping packets (TCPDUMP Drop filter)