GlobalProtect agent external gateway region restriction - portal still accessible

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.

GlobalProtect agent external gateway region restriction - portal still accessible

L4 Transporter

I have a couple regions listed under the external gateway config of our GlobalProtect Portal Agent and yet the Portal still is allowing testing of user logins from outside those regions.  For example I have US,CA,IN in there and still see regions FR,RU trying portal logins.

What/How do I stop that so the portal is only accessible from those regions?

 

Also, I see the log entries for the portal in the GP logs for the source address but when I look for those addresses in the traffic log I don't see entries for them despite all the GP related security policies having logging turned on.

 

Palo support wasn't a whole lot of help at the time but to be fair its being researched a bit - just figured this was a simple matter and doesn't appear to be.

 

Can anyone offer some guidance?

11 REPLIES 11

Cyber Elite
Cyber Elite

Is your GlobalProtect portal running on WAN interface or DMZ interface?

If on WAN interface then maybe those logins will match to intrazone-default that is not configured to log by default.

You can use security policies to permit traffic to GlobalProtect portal only from specific countries (expects portal to run on non-wan interface or ruleset to have "block any" rule at the end before default rules).

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

The portal is attached to our Outside WAN interface.  I wondered if this was considered INTRAZONE and maybe why it isn't be logged. I'll try logging that traffic for a period to see what turns up.

 

My issue for the BLOCK rule for the Portal is I don't even know what to block without risking cutting off access to something else unintentionally.  The security rules configured now are for our GP zone but I don't think that is where portal traffic hits.  Do you or someone have an example of a block rule that targets the portal traffic only?  Would it simply be blocking HTTPS traffic on the outside interfaces IP address in our untrusted outside zone?

L6 Presenter

Yes, the Portal and Gateway interfaces (on the WAN) is an Untrust-to-Untrust zone. We use an allow SrcZone:Untrust DstZone:Untrust rule with SrcAddr:US region restriction. This is fairly open and could be much more secure, but all our servers are in a separate DMZ zone (and thus follow other rules) and our PA interfaces are restricted to ping management. This can also be further restricted, we are also using an Untrust-Untrust rule with a specific country code and AppID:panos-global-protect for users on foreign travel to allow inbound GP connections. We then use a final deny Any-Any rule before the intrazone-default to block everything else.

Appreciate your comment.

 

My issue is I do not at this time know what other Untrust->Untrust zone traffic is being allowed and don't want to cut it down to US only for ALL.  I specifically want to target the Portal itself.  Would the AppID:panos-global-protect with a deny outside of the US (and other countries we don't want to allow) work?

Cyber Elite
Cyber Elite

If your GlobalProtect portal and gateway run on Untrust interface and with default config then you can permit apps below from countries your wish GlobalProtect to work from towards Untrust interface IP:

web-browsing

ssl

ipsec

panos-global-protect

 

After that drop tcp/443 and udp/4501 traffic to that Untrust interface IP from any other source.

 

If users inside the company also use GlobalProtect then don't forget to permit traffic also from internal networks to Untrust IP.

 

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

L4 Transporter

There was a post that I suspect was deleted mentioning port 443 and port 4501 which is referenced here: https://docs.paloaltonetworks.com/pan-os/10-1/pan-os-admin/firewall-administration/reference-port-nu...

 

I suspect I can simply block 443 to the outside interface and block portal access that way.  It isn't clear at this point if 4501 is needed to block the first stage of the login attempts to the portal by the GP Client but I'll have to check it by logging the traffic and see what it looks like.

Cyber Elite
Cyber Elite

Client connects to portal over tcp/443.

It will then try to connect to gateway over udp/4501 to establish IPSec tunnel.

If udp/4501 fails (some firewall blocks this traffic in between agent and gateway) then agent will fail back to tcp/443 and establish VPN tunnel over tcp/443 (slower compared to udp/4501).

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

Thank you for clarifying.  Strange, your previous post I had gotten an email on but it wasn't showing until you just posted this second msg.  That was the one I was referring to.

Cyber Elite
Cyber Elite

By default this site shows only like 5 posts per page and then you need to click "next" to see other posts.

Really annoying.

Maybe this is why you missed it.

 

I went into my account settings and set number way higher to get all posts on single page.

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

L4 Transporter

Thanks. I changed those settings also - big help.

Is all IPSEC needed or can we just get by with the ipsec-esp-udp application?

 

 

  • 3440 Views
  • 11 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!