Troubleshooting GlobalProtect

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

Troubleshooting GlobalProtect

L3 Networker

PA220, 8.1.1, GPClient 4.1.1, GP license activated. 

Connecting to the GPportal/gateway works fine. Traffic routes as expected. 
We're still testing, so access is severly limited and policies wide open once connected. Literally, everything is allowed for GP users. 
However, when i attempt to access an internal SSL-protected site, the traffic is denied. 
I can even change the rule to expressly allow SSL & web-browsing to that device and it still hits the DenyAll rule at the bottom. 

What am I missing in my setup?

1 accepted solution

Accepted Solutions

@Nathan.S,

Looking at your screenshot it looks like the log in question is being identified as looking for dst port 7443 right? Regardless the application-default port for SSL identified traffic is only 443; so if you want to allow it on 8443/7443 or whatever you need to actually specify that. As your current security policy is written this traffic doesn't match your policy. 

View solution in original post

8 REPLIES 8

Cyber Elite
Cyber Elite

Can you share screenshot of permit rule and denied log entry.

Most likely zone or user/group mismatch.

Enterprise Architect, Security @ Cloud Carib Ltd
Palo Alto Networks certified from 2011

Cyber Elite
Cyber Elite

@Nathan.S,

Aside from what @Raido_Rattameister already mentioned I would also look at the logs and verify that it's being seen on a default port and that the application is getting identified. There's a lot of little gotcha's here that can get in the way of this working properly. 

RuleRuleUnifiedLogUnifiedLog

It's showing on the correct port (443 and 8443 is what I was looking at) and being IDd as SSL traffic. 

@Nathan.S,

Looking at your screenshot it looks like the log in question is being identified as looking for dst port 7443 right? Regardless the application-default port for SSL identified traffic is only 443; so if you want to allow it on 8443/7443 or whatever you need to actually specify that. As your current security policy is written this traffic doesn't match your policy. 

Even though I have the apps set to 'any'?
huh. 
Let me look at the logs again, I'm pretty sure 443 traffic was failing too

 

@Nathan.S,

Yes; this is due to specifying the service as application-default. Since the app-id is being identified as 'ssl' the only default service that is going to be allowed is 443. 

Hmm, okay. I'll test further and will update. 

Thank you for your help!

  • 1 accepted solution
  • 5390 Views
  • 8 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!