Some webs not working

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Announcements
Please sign in to see details of an important advisory in our Customer Advisories area.

Some webs not working

L4 Transporter

Hi,

 

We have a PA-3050 with PanOS 8.0.5. We cant access to these webs https://www.metromadrid.es and https://www.ing.es

We receive a timeout and we see a RST from Palo Alto to web server.

We had this problem in 8.0.4 and we upgraded to 8.0.5 but the problem persists.

 

This issue breaks my mind, can someone give me any idea???

 

 

Captura.JPG

6 REPLIES 6

Community Team Member

Hi @soporteseguridad,

 

If there's an algorithm incompatibility then you can verify this in the PCAPs. 

The PCAP will show you the Cipher Suite the servers sends back.

 

The following information is an extract taken from https://www.ssllabs.com/ssltest where you can analyse server SSL reports.

 

https://www.metromadrid.es supports the following cipher suites :

 

# TLS 1.2 (suites in server-preferred order)
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030)   ECDH secp384r1 (eq. 7680 bits RSA)   FS 256
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f)   ECDH secp384r1 (eq. 7680 bits RSA)   FS 128
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028)   ECDH secp384r1 (eq. 7680 bits RSA)   FS 256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)   ECDH secp384r1 (eq. 7680 bits RSA)   FS 256
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027)   ECDH secp384r1 (eq. 7680 bits RSA)   FS 128
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013)   ECDH secp384r1 (eq. 7680 bits RSA)   FS 128
TLS_RSA_WITH_AES_256_GCM_SHA384 (0x9d) 256
TLS_RSA_WITH_AES_128_GCM_SHA256 (0x9c) 128
TLS_RSA_WITH_AES_256_CBC_SHA256 (0x3d) 256
TLS_RSA_WITH_AES_256_CBC_SHA (0x35) 256
TLS_RSA_WITH_AES_128_CBC_SHA256 (0x3c) 128
TLS_RSA_WITH_AES_128_CBC_SHA (0x2f) 128
# TLS 1.1 (suites in server-preferred order)
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)   ECDH secp384r1 (eq. 7680 bits RSA)   FS 256
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013)   ECDH secp384r1 (eq. 7680 bits RSA)   FS 128
TLS_RSA_WITH_AES_256_CBC_SHA (0x35) 256
TLS_RSA_WITH_AES_128_CBC_SHA (0x2f) 128
# TLS 1.0 (suites in server-preferred order)
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)   ECDH secp384r1 (eq. 7680 bits RSA)   FS 256
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013)   ECDH secp384r1 (eq. 7680 bits RSA)   FS 128
TLS_RSA_WITH_AES_256_CBC_SHA (0x35) 256
TLS_RSA_WITH_AES_128_CBC_SHA (0x2f) 128

 

https://www.ing.es supports the following cipher suites :

 

# TLS 1.2 (suites in server-preferred order)
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (0x9f)   DH 1024 bits   FS   WEAK 256
TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x39)   DH 1024 bits   FS   WEAK 256
TLS_RSA_WITH_AES_256_GCM_SHA384 (0x9d) 256
TLS_RSA_WITH_AES_256_CBC_SHA256 (0x3d) 256
TLS_RSA_WITH_AES_256_CBC_SHA (0x35) 256
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030)   ECDH secp256r1 (eq. 3072 bits RSA)   FS 256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028)   ECDH secp256r1 (eq. 3072 bits RSA)   FS 256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)   ECDH secp256r1 (eq. 3072 bits RSA)   FS 256
TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (0x16)   DH 1024 bits   FS   WEAK 112
TLS_RSA_WITH_3DES_EDE_CBC_SHA (0xa)   WEAK 112
TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (0xc012)   ECDH secp256r1 (eq. 3072 bits RSA)   FS   WEAK 112
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (0x9e)   DH 1024 bits   FS   WEAK 128
TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x33)   DH 1024 bits   FS   WEAK 128
TLS_RSA_WITH_AES_128_GCM_SHA256 (0x9c) 128
TLS_RSA_WITH_AES_128_CBC_SHA256 (0x3c) 128
TLS_RSA_WITH_AES_128_CBC_SHA (0x2f) 128
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f)   ECDH secp256r1 (eq. 3072 bits RSA)   FS 128
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027)   ECDH secp256r1 (eq. 3072 bits RSA)   FS 128
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013)   ECDH secp256r1 (eq. 3072 bits RSA)   FS 128
# TLS 1.1 (suites in server-preferred order)
TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x39)   DH 1024 bits   FS   WEAK 256
TLS_RSA_WITH_AES_256_CBC_SHA (0x35) 256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)   ECDH secp256r1 (eq. 3072 bits RSA)   FS 256
TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (0x16)   DH 1024 bits   FS   WEAK 112
TLS_RSA_WITH_3DES_EDE_CBC_SHA (0xa)   WEAK 112
TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (0xc012)   ECDH secp256r1 (eq. 3072 bits RSA)   FS   WEAK 112
TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x33)   DH 1024 bits   FS   WEAK 128
TLS_RSA_WITH_AES_128_CBC_SHA (0x2f) 128
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013)   ECDH secp256r1 (eq. 3072 bits RSA)   FS 128
# TLS 1.0 (suites in server-preferred order)
TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x39)   DH 1024 bits   FS   WEAK 256
TLS_RSA_WITH_AES_256_CBC_SHA (0x35) 256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)   ECDH secp256r1 (eq. 3072 bits RSA)   FS 256
TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (0x16)   DH 1024 bits   FS   WEAK 112
TLS_RSA_WITH_3DES_EDE_CBC_SHA (0xa)   WEAK 112
TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (0xc012)   ECDH secp256r1 (eq. 3072 bits RSA)   FS   WEAK 112
TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x33)   DH 1024 bits   FS   WEAK 128
TLS_RSA_WITH_AES_128_CBC_SHA (0x2f) 128
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013)   ECDH secp256r1 (eq. 3072 bits RSA)   FS 128

 

Cheers !

-Kiwi.

LIVEcommunity team member, CISSP
Cheers,
Kiwi
Please help out other users and “Accept as Solution” if a post helps solve your problem !

Read more about how and why to accept solutions.

I think the RST is sent before SSL negotiation. You can see it in the capture.

L3 Networker

This does not seem to be an SSL issue because we do not see even the 3-way handshake completing.

 

For the first packet from source port 57901, there is not corresponding syn ack. What is see is an 'Ack' packet from the server, which is something the client would not be expecting and thus resets the connection in the following packet. 

 

Take simultaneously pcap on firewall and client and compare packets for one particular stream.

Also, you can check global counters. On the firewall set the filter as source 10.160.74.142 and destination as 193.41.234.29.

Turn on the filter, access the website and in the cli type "show counter global filter packet-filter yes delta yes" 3 -4 times.

 

If the firewall is sending rst due to some reason, then counters should show some reason. 

Post your results.

 

Hi, i tried with web www.metromadrid.es. I attch the screenshots:

 

This is the pcap. IPs:

10.160.74.142: My ip PC

188.87.x.x: NAT publi IP Palo Alto

185.89.60.64: Web server metromadrid.es

 

Captura1.JPG

 

This is the global counter reset using filter source my IP to web server and return:

 

drops.JPG

 

What could be the reason for this RST?? thanks

in the global counters i see a warning "tcp_drop_out_of_wnd - out-of-window packets dropped". As per the packet captures the client seems to be resetting the connection because the 3-way handshake is not completing and the weird part is that it sends retransmission packets after sending rst packets. 

 

Anyway, here is an explanation as to why the firewall is dropping the packet and you can test if the command that is given below to check if it works ( Just a way to confirm the problem and not a solution).

 

tcp_drop_out_of_wnd - out-of-window packets dropped

The Palo Alto Networks Firewall creates a sliding sequence window starting with the original ACK (the window size is based on the type of traffic within the session). It is expected that the packet sequence numbers within the current session reside within this sliding window. This window adjusts with the type of traffic and whenever new ACK messages are received. The default behavior on the device is to drop packets when sequence numbers are outside this window.

 

This feature can be added to the config file and applied with a commit, which is required to override the default behavior after rebooting:

 

> configure

# set deviceconfig setting tcp asymmetric-path < bypass|drop >

# commit

 

I think the packets that you have captured are client side. It would be more helpful if you can capture the packet on the firewall as well for receive, transmit and drop stage. That way you can check what response is received from the server before the firewall drops the packet.

 

 

  • 3136 Views
  • 6 replies
  • 0 Likes
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!