A macOS fix is pending to correct an issue seen in AnyConnect version 4.8.03036 (and later) related to the nslookup command, namely nslookup not sending DNS queries through the VPN tunnel with split-include tunneling configuration. Subsequently we later found during testing that some DNS requests arent being sent over the VPN DNS and are instead going out locally via the SKY router onto the internet (So there was no access to network resources / sharepoint) To test if it was a TCP/IPv6 issue - the protocol TCP/IPv6 was disabled for the wifi adapter. When split DNS is configured in the Network (Client) Access group policy, AnyConnect tunnels specific DNS queries to the private DNS server (also configured in the group policy). All other DNS queries go to the DNS resolver on the client operating system, in the clear, for DNS resolution. This is because NSLookup does not rely on the operating system (OS) DNS resolver, and therefore, AnyConnect does not force the DNS request via a certain interface. So I am back at square one. I debated tunneling all DNS requests, but seems unfair for only 5 users having a problem. In that case, it sounds like the customer's VPN is not set up for split DNS. With split DNS, the VPN concentrator gives your VPN client a list of DNS servers (as it currently does), and also a list of domains that are the only domains that should be used with those DNS servers; all others would use your system's default DNS.
Recently I setup a PoC for remote users with Anyconnect client and OpenDNS. The idea is to control DNS queries on split tunnel RA VPN connection based on organization’s acceptable use policies and to protect from malicious threats on the Internet.
I went with OpenDNS Virtual Appliance deployment option to have visibility into client IP addresses. OpenDNS Appliance serves as DNS server and forwards internal requests to internal resolvers and external to dedicated OpenDNS servers on the Internet. Logic is depicted below.
OpenDNS Appliance footprint is very small and one-page setup makes it really easy.
Policy configuration is straight forward and accessed from OpenDNS portal under Configuration > Policies.
You can reuse default policy by tweaking Category settings and leaving Security Settings as-is.
Note: Add your local domains to System Settings > Internal Domains otherwise they will not get resolved.
Next step is to update Anyconnect Connection profile with OpenDNS Appliance IP addresses under Configuration > Network (Client) Access > Anyconnect Connection Profiles > Edit Profile.
However, my first test results were unsuccessful. I was able to browse to internal and external sites so DNS resolution was working, however sites from blocked categories were also allowed and not recorded on Categories reporting page.
Note: It may take 15 to 20 minutes for results to show up in the OpenDNS portal after inital setup.
I came across Interoperation between AnyConnect and the OpenDNS article which was great. It goes into a lot of details about DNS handling by Anyconnect but it did not help because it was geared toward roaming agent and specifically tells you that Split-tunnel-all-dns must be disabled in all of the scenarios.
To fix my issues I actually needed the opposite and this is why. The Send All DNS Lookups Through Tunnel field instructs the AnyConnect client to resolve all DNS addresses through the VPN tunnel. Setting this option ensures that DNS traffic is not leaked to the physical adapter and disallows traffic in the clear.
Anyconnect Dns Not Working
Note: If DNS resolution fails, the address remains unresolved so it is very important to setup at least 2 OpenDNS appliances for redundancy.
The configuration below depicts necessary changes to force all DNS queries to go to OpenDNS Appliance. It is configured under Group Policy > Edit Policy > Advanced > Split Tunneling
Anyconnect Dns-server Value
Once changes were applied I got a block page for restricted category and request was recorded on the portal.
One more thing to note. If Anyconnect profile is configured for Full tunnel configuration then all traffic from the endpoint will be sent across the VPN tunnel and the above change is not required.