- Access exclusive content
- Connect with peers
- Share your expertise
- Find support resources
10-03-2017 01:04 AM - edited 10-03-2017 01:07 AM
Hi,
We have a PA in 8.0.4 version and we cant access to this web https://www.metromadrid.es. The only web is not working is this.
We tried to create a rule permitting all traffic, without any profile, but its not working. We see the session like allowed, packets sent and received, but browser stuck loading and web is not showed.
this is the session created:
This is the pcap
Do you see any strange behaviour in this web https://www.metromadrid.es ?
10-03-2017 01:08 AM - edited 10-05-2017 07:29 AM
Yes, it is not accessible here in UK. from the PCAP we can see the missing 3-way handshake and constant re-transmit of the SYN packets. Most likely web server is down.
EDIT:
hmm l think it is UP now:
10-03-2017 01:23 AM
Server is UP, we can access from another PA.
Yes, its seems like 3-way is not done but in session details we see packets sent and received.
I thought that could be a problem of our ISP with that web or in the server side but a colleague told me that if he accessed using his iphone worked with IOS 9 and 10. Quite strange.....
10-03-2017 01:30 AM
Get another PCAP. l want to see SYN,ACK from the server arriving at the PA eth1/2
10-03-2017 01:55 AM
I add a pcap. i tried first with chrome (not working) and then with Firefox and now its working. If i use chrome after start session with firefox, its also working with chrome. Its like if the session is started with https is not working in both browsers, but if i start the session with http://metromadrid.es in Firefox the session is established. After being established the web is wowking in both browsers. What could be cause this problem???
This is the Firewall.pcap.
10-03-2017 02:38 AM
Thi is a bit confusing now. New tab in the web browser = new session for Palo. It doesn't matter Chrome or Firefox first, for Palo it is a new session. Did you try to test from the different client/PC?
10-03-2017 02:56 AM
Yes, all devices going through this PA have the same behavior.
With firefox i try: https://www.metromadrid.es/ and it doesnt work, then i try http://metromadrid.es and it works.
I go to "session browser", i close all sessions to web server, i try with chrome or firefow and its working with both.
I dont find any pattern
Im trying to find any different between http request from our browsers. Maybe http get or connect are different.
Quite weird.
10-03-2017 06:41 AM
Is your policy configure with "any application " "any services" and without the security profiles attached. If not then worth to test.
10-03-2017 07:12 AM - edited 10-03-2017 07:26 AM
i did that. Even i created a custom app with "http-get=metromadrid.es" but it doesnt work because threeway is not done when its not working....
I disabled DSRI, deleted zone protection in untrust interface... i dont know what more i can do :S
Quite weird.....i dont have any idea whats happening
10-03-2017 07:29 AM - edited 10-03-2017 07:29 AM
Hmmmm.. Any intermediate devices before or after the FW that could potentially interfere with this session?
Can you post successful and failed https session output using the "magnifying glass" option (eg):
It is hard to prove but l doubt it is PA issue 😄 lets see
10-03-2017 07:39 AM
Yes, but if i try http://metromadrid.es in Firefox is working fine. After that i go to chrome, i go to metromadrid.es and its working too. Quite weird.....
Here screenshots and policy.
10-03-2017 08:03 AM
using http://metromadrid.es, there is a redirect to https and its working but only in firefox and explorer.
10-03-2017 08:15 AM
This is very weird. Ok let's try something else. Lets see if PA itself can get 3-way handshake using its external (NAT IP) address;
> ssh port 443 source 188.x.x.x host 185.89.60.64
PCAP filter:
capture all stages: firewall, drop, receive and transmit.
10-03-2017 08:45 AM
I think
Log detailed:
Drop pcap:
Firewall pcap:
Transmit pcap:
receive pcap:
10-03-2017 08:56 AM - edited 10-03-2017 09:01 AM
This issue just breaks my mind 😄 l also have no ideas now. Just for test allow only application https (SSL) and on its default port 443 "application-default", otherwise l am giving up, sorry. It is more like a guess now. Cannot understand why we don't see SYN, ACK from PA PCAPs, when you were testing from the client PC with HTTPS requests.
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!