Strange behaviour via Palo Alto Firewall.

Showing results for 
Show  only  | Search instead for 
Did you mean: 

Strange behaviour via Palo Alto Firewall.

L7 Applicator

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


L6 Presenter

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




Cyber Elite
Cyber Elite

Hi @Mick_Ball ,


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





Help the community: Like helpful comments and mark solutions.

L6 Presenter

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.

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.

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

L7 Applicator



SSL Labs shows as below...


and Palo is dropping packets (TCPDUMP Drop filter)




Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

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!