GlobalProtect agent external gateway region restriction - portal still accessible

[TonyDeHart]

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?

[Raido_Rattameister]

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).

[TonyDeHart]

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?

[Adrian_Jensen]

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.

[TonyDeHart]

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?

[Raido_Rattameister]

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.

[TonyDeHart]

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.

[Raido_Rattameister]

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).

[TonyDeHart]

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.

[Raido_Rattameister]

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.

[TonyDeHart]

Thanks. I changed those settings also - big help.

[TonyDeHart]

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