u/Fallingdamage

Recently configured dialup IPsec /w IKEv2 and Azure SSO; Mode Config, IPs assigned from a specified range. Works great. No issues really.

DNS settings for the tunnel are configured for the internal DNS servers behind the VPN so clients can lookup specific resources. Split tunneling is enabled. Again. Test working!

Today I configured some new split-brain zones on our DNS servers to handle external access to an Internal/Exteral resource (PBX). To keep the tunnel traffic down, I setup a zone record to provide remote hosts (Hosts with IPs matching the IP Range in the VPN config) with the public IP of our PBX. That way when DNS lookups are done, the PBX's public IP is returned from the internal DNS server to those hosts. No need to use VOIP over the tunnel.

Firewall policy as its been working is VPNINTERFACE > LAN , VPN_Range > LAN_Range , (Services) > Allow

when connected, nslookup still resolves to the internal IP. The internal DNS server is not applying the dns policy to the VPN IP range and returning the public IP like it should.

So then I changed the firewall policy by turning off NAT.

Reconnected to VPN. nslookup resolves public IP of our PBX properly. now. DNS server receives DNS lookup from IP matching subnet in the DNS Zone policy and sends the proper response based on that policy. So my question:

TLDR; when NAT is enabled this policy, what is our DNS server thinking its getting its DNS requests from if its not getting them from the IP range in the policy?? Disabling NAT fixes the issue.

So ive spent some time today getting switched over from SSLVPN to IPSec. IKE2 /w Azure SAML SSO. Got it functioning reliably and predictably.

Updated some of my Forticlient provisioning scripts to make sure I can push the config smoothly on PCs that utilize it. Finally, while thinking about how I will roll this out, I did a little testing on a hunch to see how forticlient behaves while in use.

I found that while connected to our SSLVPN, if you have remote access to the PC, you can push a new config to the VPN-only forticlient WHILE its actively connected. When the user disconnects, the previous SSL option wont be there anymore and the new IPsec settings will be in place. There IS an easy way to only append the new connection to forticlient without erasing the current config, but I'm not covering that here.

$VPNConfigXML = "-m vpn -f C:/Temp/IPSECConfig.xml -o import -p thepassword"  
Start-Process -FilePath "C:\Program Files\Fortinet\FortiClient\FCConfig.exe" -ArgumentList $VPNConfigXML  

Copy the config file to the remote PC (unless you're using redirection) while the user is connected. In the XML, update the 'Local ID' field for the connection to the employees name or location and run that command. Next time they disconnect, they will see the new connection in their Forticlient.

In the IPSec phase 1 settings, the client ID was set to 'Any ID' and differentiating the Local ID in the forticlient config file helps to quickly tell who is connected in your ipsec table. Using get vpn ike gateway | grep "user|assigned" is another way to see who's connected, but its nice to give your clients names the GUI will present.

There wasnt much documentation on whether forticlient would take a config while actively connected. This is going to save me a lot of time since we dont use the full EMS service.