How to force users on the LAN to use a specific DNS server using ARP poisoning

Experiment

There is a lot of conflicting information about what actually happens on a Windows client when using split-dns. So much that I decided to gather some evidence and see where it points. I set up a simultaneous packet capture on both the VPN-connected Windows client and the ASA to which that client is connected. Here is a diagram of the test setup:

With the packet captures running, I initiated DNS resolution on the client. To do so, I pressed enter on srv1.internal.example.com in Google Chrome. Here are the resulting packet captures adjusted to sync their clocks and merged together.

Packets with IDs starting with "C" are from the Windows [C]lient.
Packets starting with "A" are from the [A]SA.

Analysis

In orange, we can see four separate DNS queries that are trying to be made by Windows/Chrome: The destinations of the four DNS queries are as follows:

• 8.8.8.8 - the DNS Server associated with the Wifi Adapter (packet C69)
• 10.10.10.3 - the first DNS Server associated with the VPN Adapter (packet C70)
• 8.8.8.8 - the DNS Server associated with the Wifi Adapter (packet C78)
• 10.10.10.4 - the second DNS Server associated with the VPN Adapter (packet C81)

What is most revealing is that the two DNS queries apparently sent to 8.8.8.8 appear at the ASA in packets A95 and A105 with source and destination IPs translated from external addresses to internal addresses. The responses from the DNS server for those translated queries are in A97 and A106 which are themselves then translated to external addresses again in packets C74 and C84, respectively. These DNS queries ultimately succeed.

Answers to the original questions

If Windows opts to send DNS queries for internal domains to adapters other than the VPN adapter, how can the VPN client ensure all DNS queries for internal domains are tunneled to the internal DNS servers?

Based on the above evidence, the VPN client seems to intercept DNS queries that match the domain configured using the split-dns value command on non-VPN adapters.

Am I missing something here? Is there something fancy going on that somehow allows the VPN client to intercept DNS queries that Windows sends to the wrong adapter?

The fancy part that was missing is that the VPN client performs a sort of network address translation to make it appear to Windows that DNS queries for the internal domain are being serviced by the public DNS server to which Windows sent its request. In fact those requests are serviced by the internal DNS server.

I'm not sure exactly how this is accomplished, and there doesn't seem to be any documentation from Cisco that speaks to this. I accept that there is some amount of sorcery that the VPN client performs on the Windows end to achieve a functioning split DNS.

Notes on Adapter Binding Order

I tinkered with the oft-cited adapter binding order. Here is what I found. The adapter order seems to have no impact on the efficacy of the VPN Client's ability to intercept and translate DNS queries for internal domains.

Putting the VPN adapter highest in the binding order seems to result in Windows sending DNS requests only to the DNS servers on the VPN adapter initially. Those requests seem to be dropped entirely by the VPN Client (presumably because they don't match the internal domain). This then results in a Windows timeout (or a series of them) until, eventually, Windows attempts DNS resolution using the non-VPN adapter. This creates a noticeable and irritating delay when browsing.

Based on this, it seems that in split DNS configurations the VPN adapter should not be the highest priority.

You're going down the correct path, you need a route for your local LAN. But you need a route back from your LAN machine. At the moment it only has a default route of X.Y.Z.254 so sends all its traffic not on the local LAN here. Theres 2 options:

1. Add a route on your gateway router, if its a half decent after-market router you should be able to add a route to 10.0.8.0/24 pointing at your pfsense box. So any traffic going there will be directed out the OpenVPN route.
2. If you cant add the route then for every device you will need to add a static route to the VPN clients so it knows that subnet exists through the pfSense box.

For Windows:

route add 10.0.8.0 mask 255.255.255.0 X.Y.Z.pfsense -p

^^ replace the IP on your LAN with that of the pfsense box, the P flag is to permanently add it to the routing table

For Linux:

ip route add 10.0.8.0/24 via X.Y.Z.pfsense

^^to persistantly add it varies per Linux distro