Global Protect Internal Host Detection & Internal Gateways - Lessons Learnt

I already had Palo Alto GlobalProtect VPN configured with an external gateway and portal, allowing me to connect back to my home network when I'm outside. Even when I'm inside my internal network, I can still connect to the VPN. However, I wanted to use the Internal Host Detection feature of GlobalProtect VPN, so that if I'm on my internal network and try to connect, it won't connect to the external gateway. Throughout the configurations, I learned a few lessons. Let’s dive in.

If you're completely new to GlobalProtect VPN, please check out my introductory blog post linked below.

Please note that this setup was tested on PAN-OS 10.2.9-h1 and the GlobalProtect macOS client version 6.2.4.

What is Internal Host Detection?

If you're already in your office or internal network, there's no need to connect to the VPN, what’s the point, right? This is especially relevant if you're using an 'Always-On' VPN. When users are in the office, we want to tell the Always-On VPN not to establish a tunnel, meaning it shouldn’t create a VPN connection from the internal network to the firewall.

Internal Host Detection works by specifying an internal domain and its corresponding IP address on the firewall. When the GlobalProtect client attempts to connect to the VPN, it first tries to perform a reverse lookup for that IP. If it resolves successfully and the result matches what we have configured on the firewall, it knows the client is already inside the office. Since this domain is internal, it won't resolve if the client is outside the internal network.

Internal Host Detection Configuration

To configure Internal Host Detection, navigate to Network > Portal > Agent > Agent Config > Internal. Here, you need to specify a domain and its corresponding IP address. Note that the firewall performs a reverse lookup, so the IP should resolve to the specified host.

You can create a dummy entry on your internal DNS server for this purpose. The firewall doesn't attempt to connect to this host; it simply performs a reverse lookup.

As I was making this change, I tried to connect to the VPN while inside my network, but it still connected to the external gateway, as if I were outside. It turns out that this feature only works with an 'Always-On' VPN. If your 'Connect Method' is set to 'On-Demand' Internal Host Detection won't work, and the client will connect to the external gateway.

So, I changed the 'Connect Method' to 'Always-On' and it worked straightaway.

Global Protect Internal Gateway

If you only configure Internal Host Detection without setting up an Internal Gateway, the primary benefit is that the VPN won't establish a tunnel when you're inside the network. However, you won't receive any User-ID or HIP data.

On the other hand, if you configure an Internal Gateway, the GlobalProtect client still authenticates without creating a tunnel, which allows it to pass User-ID and HIP information.

In my example, let's say my local subnet is 192.168.0.0/24 and the associated zone is 'LAN'. I can create an Internal Gateway using this interface and configure it similarly to an external gateway (including authentication and certificate profiles), except for the tunnel configuration, just leave that part blank, as we still don't want to create a tunnel.

To create an internal gateway, navigate to Network > Gateway and select your internal interface. Under authentication, you can use the same Certificate Profile and Authentication Profile as the external gateway. I left the 'Agent' section at its default settings.

Now, under Portal > Agent Settings, add the newly created Internal Gateway.

I committed the changes and reconnected to the VPN.

As you can see, now even though I'm inside my network and not connected to a VPN tunnel, the firewall starts collecting the User-ID info.

Automatic Restoration of VPN Connection Timeout

With 'Always-On' VPN, if a user switches from an external network to an internal network before the timeout value expires, GlobalProtect does not perform network discovery. As a result, GlobalProtect reconnects to the last known external gateway. Of course, if I click 'Refresh Connection' it disconnects from the external gateway.

In my case, if I connect my laptop to a mobile hotspot and then walk into the office and connect to the office network, I am inside the internal network, but the VPN still connects to the external gateway; it doesn't automatically switch to the internal network. It does work the other way though, if I move from my internal network to the mobile hotspot, it automatically connects to the external gateway.

Under Portal > Agent > Automatic Restoration of VPN Connection Timeout, you can specify a timeout value (in minutes) ranging from 0 to 180 to determine what action the GlobalProtect app takes when the tunnel disconnects due to network instability or changes in the endpoint state. By default, this value is set to 30 minutes.

• 0 — Disables this feature, meaning GlobalProtect will not attempt to reestablish the tunnel after it's disconnected.
• 1-180 — Enables this feature, meaning GlobalProtect will attempt to reestablish the tunnel connection if it goes down, as long as the downtime does not exceed the specified timeout value.

If you set the value to 0, the connection to the external gateway will disconnect as soon as you enter the internal network.

Here is my screen recording, you can see that when I'm connected to my WiFi (internal network), it switches to the internal gateway. However, as soon as I disconnect from WiFi and connect to the hotspot, it connects to the external gateway. If I reconnect to the WiFi, it switches back to the internal gateway again.

A Few Things to Note

When you configure the internal gateway, you can use either an IP or an FQDN. In my example, I'm using an IP. However, you'll need to update your certificate to include this IP alongside your portal/external gateway.

I typically set the common name of the certificate to match the portal/gateway and then add SAN fields to include the portal/external gateway again, along with the internal gateway IP. If you don't include the gateway IP/FQDN in the certificate, the VPN won't work, and you'll see an error message in the debug log.

Another thing to note is that for the zone associated with the Internal Gateway, you need to enable 'User Identification'. Otherwise, User-ID won't work.