Some organizations may choose to setup their remote access VPN to enable the VPN to connect automatically prior to a user logging into the machine. There may be a number of reasons for this, but in this case the VPN client must use a machine certificate to authenticate to the VPN.
I have encountered the below situation in regards to this pre-logon VPN setup. A machine with Global Protect and always-on with pre-logon settings reboots and is sitting at the Windows login screen. The machine successfully authenticates to the VPN using a machine cert. Now, the user logs into the machine. What should happen is that the Global Protect client detects a user login, then changes the VPN session from “pre-logon” to show the actual user logged into the machine. This could be from single sign on credentials or also use a user certificate to authenticate to the VPN.
This process is well documented and should happen seamlessly. However, the documentation doesn’t mention that the Global Protect agent will actually attempt another DNS request for the Global Protect gateway. So, let’s assume the gateway address is vpn.example.com. Prior to any VPN connection, the machine uses whatever DNS servers are configured, let’s assume 8.8.8.8 and 1.1.1.1. This then uses public DNS to resolve vpn.example.com to its public IP and the connection successfully goes through.
When the user logs in, the machine is already connected to the VPN and will be using internal DNS servers. Because of this and the fact that Global Protect will do a fresh DNS request for the gateway after the user logs in, this DNS request will fail to resolve properly to the external gateway and Global Protect would fail to connect. I determined this was being done from analyzing the logs of a system that to see the DNS request fail to resolve.
So, there are two ways to fix this. One, a DNS A record can be added to the internal DNS servers that maps vpn.example.com to its public IP. The other method is to create a DNS split tunnel in the Global Protect settings to exempt the vpn.example.com from being resolved by the DNS servers over the tunnel and instead use whatever DNS servers are configured on the end system.