Allowing GlobalProtect connection via Source user

[R.Perez481389]

Hi everyone,

Our staff occasionally goes abroad and they still need to be able to work. At the moment, we need to ask them to check their Public IP and then we whitelist that. This gets a bit cumbersome, especially if they're going to 3-4 countries in 2 weeks. Is there a way to allow them to connect to GP if it identifies that it's a particular Source user that we allow in the Policy? If not, what's the best solution for this?

Thanks

[reaper]

I'm guessing the intent is to not allow anyone touching the external interface of the firewall unless they need to?

That's great for static services but gets cumbersome, as you mentioned, for moving targets. can you elaborate on the reasoning behind the access list?

It's not possible to replace source ip with source user, since the source user can only be retrieved once a connection is made. 

You should add client certificates for all users, and make sure strong MFA (with conditional access) is set up, so that unauthorised sources are not able to connect to your gateway or portal (a client cert will actively block connections before they get to the authentication part, this is a very solid measure to defend against stolen credentials or brute force)

just a funny idea i just had: you could also set up dyndns for your roaming users so they all get their own FQDN that updates as they get different IP addresses. the firewall can then be set to allow these dyndns FQDNs 😉

[BPry]

@R.Perez481389,

How do you have GlobalProtect configured for client configs? I'm assuming that you're specifying your region source-address criteria so that only your allowed countries are ever going to be allowed to connect?

What I personally do is have a dedicated range that I use for international travel, with that range having very explicit access to resources (keeping source-user requirements and the like) and preventing access to the resources that we would otherwise not want someone outside of the United States to ever be able to pull up information from. The user then gets their own dedicated remote-user-tunnel-configs which only grants their specific machine/user the ability to connect via that config. If someone were to travel with them and attempt to connect, it wouldn't match the client config and they would be unable to form a tunnel.

This would work regardless of whether you're using certificate based authentication or allowing users via SAML or something of the sort. We have automation that expands this capability and tracking which endpoints someone can use if you're allowing personal devices, but that is kind of outside of the scope of this conversation. It's something you can relatively easily do through automation and the XML API however.

We then only open up GlobalProtect access from the target geographic location on whatever travel schedule they provide to us after the country has been reviewed and accepted. This keeps the exposure smaller with minimal overhead, but I would feel less comfortable doing this if we didn't have the automation in place to monitor the endpoints connecting and failed authentication against the portal/gateway automatically being blocked.