I believe lan connection of the client has a higher priority/metric than the local one. That is normal. It depends on the name resolution order. Did you check the TCP/IP settings (Advanced settings) in the client? Check the metric of the gateway, DNS settings (DNS tab), and the name resolution order and there are other services too. IP/v6 also provides techniques.
Most importantly, there is a specific setting known as the VPN Binding Order. Imo, this could be the issue.
You could try the solution below. This is copied directly from this Microsoft article.
- Click Start, type regedit32 in the Open box, and then
click OK.
- Click the following registry subkey:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Linkage
- In the right pane, double-click Bind.
- In the Value data box, select the "\Device\NdisWanIp" item, press CTRL+X, click the top of the list of devices, and then press CTRL+V.
- Click OK, and then quit Registry Editor.
- Restart the remote system.
Note: If you use an AD enabled network, you may be able to use a policy.
I figured it out: Both online-dns
servers (customer.com
and mysite.com
) had wildcard records setup, i.e. a A-record
like *.mysite.com
Therefore, when the ad.customer.com
internal DNS was queried for a fqdn on ad.mysite.com
, it was forwarded to OUR online-dns, the online-DNS responsible for mysite.com
answered with the primary IP due to it's wildcard-A-record:
I cannot change the Domain-Records for the customer, but i can change ours. So, I configured the metrics in order that the remote
connection is used first, but for our tld, I disabled the wildcard-record, leaving only valid
hostnames to be answered.
So, if a VPN-Connection is established now, Windows will start to query the customers local dns, even for internal hostnames, but then no longer receives a wrong answer (due to forwarding to the online-dns) but nothing.
NOW Windows seems to query the dns servers of the secondary connection (local one, higher metric), which then works and leads to the correct result:
Knowing the cause, another - maybe better - solution was easy to find:
While Solution 1 would always query the customers local DNS first, this one works with querying our local dns first:
First, ofc. Metrics of the two connections have been changed, so that the local connection is used first.
Inside our local DNS-Server I setup a Primary-Zone, matching the customers domain: customer.com
- and left it empty.
Now, our local DNS will answer with not found
rather than forwarding the query to the customers wildcard-using-online-dns-server. (Which cannot resolve their internal names)
My PC will now use the second (remote) connection, where the query for internal names can be resolved.
Drawback: Without an established VPN-Connection, I can no longer access the customers website, because our local dns is no longer forwarding these queries.
If I would need that as well, I could setup A-records in the "Fake-primary-Zone" ofc.
Best Answer
https://social.technet.microsoft.com/Forums/windows/en-US/17d2d49e-7476-41aa-b49a-e4b505f54da9/windows-2008-r2-isnt-giving-clients-a-connection-specific-dns-suffix?forum=winserverNIS explained how things work in Windows quite well.
So actually RRAS takes the DNS settings of the server itself and push them to VPN clients. But since my box has three virtual NICs, although only one of them is used, I have to configure DNS for all of them.