Maybe I am overthinking this, but here is my dilemma. We have a few external websites which are only accessible from our “office” IP address. So when the user is in the office, they can get to the sites fine. However, with everyone using GlobalProtect VPN, when they try to access these sites, it is their home IP address which the site sees rather than the IP address which we have set up as “external” for Globalprotect users. So I am thinking that if I add the IP addresses of these external sites to the GP Agent Access Route, the GP Client should route the traffic to these sites through the VPN so that the person at home is able to access the site, right? But the problem is, when I add the IP addresses to the Split Tunnel access route, access to the site just times out and they get a “this site can’t be reached” message. I’m running 8.1.13 and the GP client is 5.2.3. Does this make sense? What am I missing?
Have you added that route to your VR to send the IP address out from your inside → to outside interface?
Is dns getting resolved? security policy present to allow from gpzone to wan? Source Nat policy present from gpzone to wan?
You can do split tunnel by domain also. More reliable especially since websites may change IP address without warning.
Once that domain/IP is in the configuration, check logs/tracerouts to see how traffic is flowing. You’ll need an applicable NAT and Security policy for egress traffic to the internet from the VPN.
You should upgrade your FW version. Also, split tunnels on 5.2.3+ may be having issues with FQDN names. You may want to test it out
GP makes the DNS request, then it matched the ip and puts it into the tunnel route. Sometimes when the traffic flow is already happening, the route isn’t picked up right away, especially by Macs and leaves out the local gateway not the VPN tunnel
I would put in a ticket it if continues to happen
Are these FQDN static? We have customers in this situation specifically for cloud servers where access is only achieved via their firewall’s public IP address. The FQDN for those servers do not change of course but the public address 50.1.1.12 for example will change almost hourly to 50.1.1.13, etc etc. The customer had to add the entire ip block for that cloud provider to get this to work. The suggestion by Qel_Hoth is legit but you will have to upgrade as 8.1.x does not support domains in a split-tunnel configuration. Check the monitor tab on the firewall during a test connection to see if traffic going outbound from the VPN internal ip to the FQDN.
Revew your NAT rule to include the source zone where the GP resides in.
I agree here that the latest GP versions might have an issue with FQDN split-tunnel. I tried to split-tunnel Microsoft update FQDNs, and when I did a PCAP, I saw that none of the traffic was being excluded from the tunnel.
I only tried this once and dropped the setup at the time and never opened a ticket on it (low priority).
Perhaps I should revisit this.