Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

I have a customer that uses a VPN connection, however it automatically configures my DNS settings to a non-existent DNS server, meaning every DNS resolution times out until the alternative is tried, which really slows down all Internet traffic.

Is there a way that I can prevent an application from overriding my DNS settings (without enabling UAC)?

Alternatively, is there a way that I can set up some kind of local routing that says 'when a DNS request for IP address A comes in, actually use IP address B'?

I'm using Windows 8 Developer preview (but I suspect it should work the same as Windows 7).

Thanks

share|improve this question
add comment

4 Answers

up vote 12 down vote accepted

I don't believe there is a way to prevent it from happening, apart from statically assigning the DNS servers on the VPN connection.

To change the order in which DNS servers are queried, one is supposed to be able to change the interface binding order as per http://superuser.com/a/314379/120267, but that doesn't seem to affect VPN connections in my personal testing on Windows 7; I've confirmed that my VPN connection is consistently added to the top of the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\Tcpip\Linkage\Bind list, regardless of the interface binding order settings.

However, you can reset the DNS changes after the VPN connection is established.

Collecting Information

Open up a command prompt (Start -> Run... -> cmd) and then run netsh interface ipv4 show dnsservers. You will see output similar to the following:

Configuration for interface "My VPN"
    Statically Configured DNS Servers:    11.22.33.44
                                          55.66.77.88
   ...

Configuration for interface "Local Network Connection"
    DNS servers configured through DHCP:  192.168.0.1
                                          192.168.0.2
    ...

You need the interface name for the VPN, and optionally your non-VPN connection's first DNS server. In this example, they are My VPN and 192.168.0.1, respectively.


Setting It All Up

Option 1: Disable VPN DNS

Assuming you don't need your VPN's DNS servers at all, you can simply run the following in the command prompt:

netsh interface ipv4 delete dnsservers name="<Interface Name>" address=all validate=no

Eg: netsh interface ipv4 delete dnsservers name="My VPN" address=all validate=no

If you run netsh interface ipv4 show dnsservers again, you will see that the DNS servers associated with the VPN have been removed; your non-VPN connection's DNS servers will be used to resolve hostnames.


Option 2: Supplement VPN DNS

If you need your VPN's DNS servers to resolve intranet hostnames, you can run the following in the command prompt:

netsh interface ipv4 add dnsservers name="<Interface Name>" address=<Non-VPN DNS server> index=1 validate=no

Eg: netsh interface ipv4 add dnsservers name="My VPN" address=192.168.0.1 index=1 validate=no

In this case, netsh interface ipv4 show dnsservers will show that your non-VPN connection's first DNS server has been added to the top of the list of your VPN's DNS servers. It will be used to resolve hostnames first, and if unsuccessful, fall back to using your VPN's regular DNS servers.

share|improve this answer
    
You are a hero sir, thanks for the extensive answer, it seems to work fine! I tried messing around with netsh but didn't manage to get this far... –  Zidad Feb 29 '12 at 13:29
add comment

Is there a way that I can prevent an application from overriding my DNS settings (without enabling UAC)?

At least there is no easy way to do that.

Alternatively, is there a way that I can set up some kind of local routing that says 'when a DNS request for IP address A comes in, actually use IP address B'?

You can add entries to the hosts file (C:\Windows\System32\drivers\etc\hosts). This file contains mappings from host names to IP addresses and is preferred over DNS requests.

share|improve this answer
    
Well I know about the hosts file, but this is all IP address based so that doesn't work unfortunately... –  Zidad Feb 21 '12 at 9:57
    
Oh, ok, now I get your question. And no, you cannot redirect requests from one IP to another. –  Michael Feb 21 '12 at 11:22
add comment

Can you check the status of the 'Use default gateway on remote network' checkbox. This is found by opening the properties of your VPN connection and go to Networking tab and select either TCP/IP v4 or TCP/IP V6 and then select properties and then advanced. This may be enabled which could mean that all internet traffic is routed over the VPN connection.it is not always possible to disabled this and still do what you want with the VPN, but it can be disabled, it might speed up internet access.

If that doesn't help, there is a DNS tab there and you could try adding your DNS servers there. I have tried this, but I would expect these settings to override the automatic settings.

share|improve this answer
    
It's not checked, so it's not routing all internet traffic over VPN (when the name is finally resolved the connection is fast enough). I tried changing the DNS settings there, but unfortunately it's all changed back automatically to the invalid DNS settings when I restart the connection :( –  Zidad Feb 21 '12 at 10:02
    
If you can't stop the DNS being changed, is it possible to get it to fail faster by using a firewall to block DNS requests to this address? –  sgmoore Feb 24 '12 at 16:09
add comment

I had a similar problem; connecting to a VPN server would override my workstation's (remote VPN client) DNS so that the local LAN DNS would be obscured. I described the problem more in detail on Stackoverflow side before I was pointed out that I should've posted it here instead.

Having read through this thread it is apparent that the override can't be prevented using the OpenVPN client configuration. My solution was to add a batch file in the OpenVPN config directory that executes when the OpenVPN connection is formed. If the OVPN file is called company.ovpn, the file that is run on connect needs to be named company_up.bat.

I've augmented the file some since the version I posted to my question in StackOverflow earlier tonight. Now it looks like this:

1: ping 127.0.0.1 -n 2 > nul
2: netsh interface ip set dns "Local Area Connection 4" static 127.0.0.1
3: route delete 0.0.0.0
4: route add -p 0.0.0.0/0 172.20.20.1 metric 1000
5: exit 0

1: A hack to wait for couple of seconds before proceeding. The latest version (2.3) of OpenVPN client would ignore the DNS and route changes if executed without a delay.

2: Set the DNS of the VPN connection to point to the localhost. I have a resolver (I use SimpleDNS Plus) running on the localhost that forwards the queries to the company domain to the company DNS server over the VPN, and everything else to the local LAN DNS server. Note that I could not use a local LAN resolver to forward the queries for the company domain to the company DNS over the VPN since the VPN endpoint is on the localhost. The connection name ("Local Area Connection 4") was determined at command prompt via "ipconfig /all".

3: The company VPN server is configured to route all the outbound traffic through the VPN while at the same time restricting outbound (to the Internet) SSH connections. This conflicted with my workflow, and I'm first deleting the "0.0.0.0 netmask 0.0.0.0" route...

4: .. and then I re-add the 0.0.0.0/0 route to point to the local LAN gateway, and set its metric (weight) to 1000 as a catch-all for all traffic that is not routed otherwise.

5: Without "exit 0" OpenVPN spits out an error warning of the script failed (with an exit status 1).

Hopefully this is useful for someone.. it's working reasonably well for me (no need to make route or DNS adjustments manually every time I open a connection).

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.