Not able to access an website via Palo Alto firewall

[tamilvanan]

Hi Folks,

We are recently receiving multiple cases where the devices behind the PA firewall is not able to access certain websites.

In an recent case we had seen for two devices (Device A and Device B in different VLAN's ) located behind Palo Alto firewall from device A we are able to access the website but from device B we are not able to access to the site.

In PA firewall we had created an security policy and placed on the top with any for application and services allowing the two source IP addresses 10.12.10.159 and 10.82.192.17. Checked routing and symmetric return is happening.

We had done packet captures and done the analysis for both the devices A and B. In both the working scenario(Device A) and Non-working scenario(Device B) no packet drops were observed on the firewall and also in the traffic logs no block/threat log or drop logs are created for the source and destination flow.

In the non-working scenario after server hello during the SSL/TLS handshake the client is sending the RST,ACK to the server.

In the working scenario we could see the TCP 3-way handshake and the SSL/TLS handshake is happening properly without any issues and the Application data is also going properly. 

Working Scenario (C:10.12.10.159-->S:40.126.35.130)

Non-Working: (C:10.82.192.17--->S:40.126.35.130)

I just wanted to know whether the firewall is sending this RST,ACK packet or the firewall is causing any issues here.

Attached the PACP screenshots to the post.

Non-Working:

Working-Scenario:

[BPry]

@tamilvanan,

Have you looked at your firewall logs and verified that the traffic is actually being allowed and that it's not resetting traffic from 10.82.192.17 for any reason? That's really the place to start with something like this; look at the logs and determine what the firewall itself is seeing and if the firewall is allowing that traffic. You don't mention if your temporary security entry to allow traffic is still using any security profiles or that you've verified the traffic is actually hitting that test entry. 

In your PCAP what you're seeing with the RST/ACK is simply the device acknowledging whatever data was sent previously in the sequence, and then notifying the 20.190.163.22 to close the connection with the RST. The firewall isn't sending that RST. 

[aleksandar.astardzhiev]

Hi @tamilvanan,

- On which side of the firewall did you capture the traffic?

- The ACK/RST is not actually relevant in this case, because it is for different connection (Server Hello come from 40.126.35.130, while the RST is to 20.190.163.22)

- From the non-working PCAP you can actually see that client (10.82.192.17) not receiving the Server Hello, which by the way is split in four packers, because it is too large). For that reason, client is re-transmitting its last packet, effectively asking the server to re-transmit it last segment.

- You mentioned that multiple devices are experience the same issue - have you made any connection between the working one and none working one? Are they in different VLANs? Are they using different network devices (switches, routers etc)

This PCAP remains me of a case several years ago, that I will never forget...

We were troubleshooting case where devices were not able to access web page over HTTPS, while the server was working fine and same page was accessible from other networks without issues. We notice similar re-transmissions when server tries to send "Server Hello". Because "Server Hello" contain certificate chain and other crap, it is too large and split into several packets, but still large packets. We figure out that larger packets are dropped somewhere along the path before reaching the client and it was not able to complete the SSL negotiation. It may sound bizarre, but at the end it turns out that bad cable was causing packet loss between two switches. Smaller packets were forwarded without problems, but anything bigger than 1300 was lost.

I would suggestion you:

- Check all physical interfaces along the path between client and firewall for errors (this includes switches, routers and any other network devices, not only the firewall)

- Check for duplex and speed mismatch on same interfaces

- Run packet capture directly on the problematic hosts and on the firewall (on the interface facing the client) at the same time and confirm that all packets seen by the firewall are received by the client.