Local vs VPN DNS Name Resolution

[johnpoz]

"With out local network access being blocked of course."

Well if the local dns is on the local dns, its up to the client what he uses - you can hand out dns when they connect for the vpn.  And if the dns they decide to use was off their network then they would have to go through the vpn to get there, etc.

But if dns they are using local and you want to allow local access, then you need to have the client make sure they use the dns you hand out from your vpn first - take a look at your binding order.

[NOYB]

My binding order does not show any OpenVPN item.
(Windows 8.1 Pro)


[johnpoz]

Your on provider - I renamed mined, your is prob called tap, etc.  Whatever the default is.. Switch over to adapters and bindings.  What does it show?

[NOYB]

Ah okay I see.

Yes in Adapters and Bindings my TAP device is named Local Area Connection.

I'll try moving it to the top of the list and see what that does to the name resolution.

Thanks for the pointer.

[NOYB]

Well that's a little bit of an improvement, but not much.

Queries for internet names (non-local and non-vpn) using nslookup all go to the VPN DNS exclusively.  This is the desired behavior.

However, for browsing, queries still go to both the local and VPN DNS servers and responses are received from both.  The desired behavior would be for only local name queries to be sent to the local DNS server and all other name queries to be sent to the VPN DNS server.

[johnpoz]

"  The desired behavior would be for only local name queries to be sent to the local DNS server and all other name queries to be sent to the VPN DNS server."

That is not how dns works..  You would have to run a nameserver on your local box - and create forwarder rules, so all your KNOWN local went to your local dns server, and everything else (non local and internet went to whatever other dns you wanted to send it to)

What do you mean by browsing btw, like \somename or ping hostnameonly ?

Browsing is not a dns thing.. queries for FQDN are what dns is for.. if your client is sending hostname to dns how do you expect it to resolve in the first place without domain to look up that the name server either forwards on, or is authoritative for..

What response are you getting from your vpn dns, it sure and the hell would not know about your local zones?

please give a detailed example of for starters how you know where the queries are going and what your getting back for an answer.. window client does not query all the dns servers it has listed at once.. It will query one, if it doesn't get answer it will go onto next, etc..

What version of windows is this client?

[NOYB]

Using Wireshark to capture both the WiFi and VPN networks.  Filter on port 53.

Query for nslookup yahoo.con goes to the VPN DNS only.  As desired.

However,
Browse (IE) to http://yahoo.com and the name queries go to both the local (192.168.1.1) and VPN (192.168.2.1) DNS servers.  And resolved addresses are received from both.

Seems like this could be a big security hole.  Possible for a public hot spot network to send clients to malicious sites even though they are using a VPN.

[johnpoz]

That is your browser doing that - not the OS..  Don't use IE for starters if your worried about security ;)

Well yeah if you query them, they will answer if they can ;)

[NOYB]

It's not just IE that this OpenVPN DNS behavior occurs with.

[johnpoz]

Its not openvpn behavior..  Openvpn has nothing to do with dns, what your os or application does with what its handed has nothing to do with openvpn.

I don't see this behavior, are you talking about queries for such like wpad ?

You see in first picture that hey I am doing dns to the dns server on my openvpn interface..

Look what happens if I ask for something like pfsense.local.lan - it asks my openvpn dns, he says NX.. Sorry..  there is no domain like that.. So client gives up..  Now if dns server had not answered, or returned serv fail, then sure would of keep trying to resolve via methods it knows how to use to resolve.

You sure your not seeing broadcasts for names – we dns your set to says fails to respond windows will get desperate and even broadcast for your fqdn even though it doesn't exist, etc.

Lets see a specific example of what your concerned with.

[NOYB]

Attachment Details:

Wireshark capture on both the WiFi and OpenVPN interfaces with capture filter 'port 53'.

192.168.1.x is local WiFi hotspot network.
192.168.22.x is OpenVPN to pfSense (configured to force all traffic through VPN and provide DNS servers list.

Browse to: https://wwws.ameritrade.com/apps/LogIn/

DNS queries for the non-local name are sent to both the local WiFi hotspot network DNS server and the OpenVPN DNS server.
DNS response received from both.  Making it possible for the local WiFi hotspot network DNS to provide an address that sends the client to a malicious site.

OpenVPN Forum Thread:
https://forums.openvpn.net/viewtopic.php?t=15939


[kpa]

Are you handing out one or two DNS forwarders during the OpenVPN tunnel set up? If you're handing out just one forwarder Windows may keep the second forwarder from the initial DHCP setup and combine it with the one it got from the OpenVPN tunnel set up. Try giving the client at least two DNS forwarders and see how it behaves then.

But yes, this has almost nothing to do with OpenVPN itself. Windows is known for its "creative adaptations" of internet standards and this is just one of them.

[johnpoz]

Well my home box that I showed was static IP on its local interface..

Its quite possible windows does something odd with dhcp.. It sure and the F shouldn't but as stated MS likes to go their own route sometimes when it comes to standards.

I vpn to my home network pretty much every single day from work, so happy to validate what your seeing.  That second query should not be happening - unless the fist 1 failed to answer or returned serv fail.  But again this has NOTHING to do with openvpn..  Openvpn just hands the client dns to use, it can not control the how the OS uses or doesn't use that info.

You did update your binding btw?  Your screenshot was of providers..  keep in mind if you enable or disable interfaces this order can and does change..  So double check it, from your sniff where the local dns was .001 second later I would assume vpn connection is first..  Its best to rename your interfaces so you know exactly what they are vs local connection 1, local connection 2 ;)

[johnpoz]

Ok - from a quick test when I got into the office, I set client to redirect-gateway def1

now get this in my route print for default, before I was not redirecting

Active Routes:
Network Destination        Netmask          Gateway      Interface  Metric
          0.0.0.0          0.0.0.0      10.56.41.1      10.56.41.36    10
          0.0.0.0        128.0.0.0      10.0.200.5      10.0.200.6    20

Now what I noticed right off the bat was that it was sending dns to my local configured dns at 10.56.144.11 and 10.56.144.21 down my vpn connection.  This is all it was doing it was not sending anything to my 192.168.1.253 dns (pfsense) down the vpn..

So as suggested I added couple more entries fro dns to openvpn config.. so it handed out 192.168.1.253 3 times

Ethernet adapter vpn:

Connection-specific DNS Suffix  . : local.lan
  Description . . . . . . . . . . . : TAP-Windows Adapter V9
  Physical Address. . . . . . . . . : 00-FF-5A-2F-7E-EA
  DHCP Enabled. . . . . . . . . . . : Yes
  Autoconfiguration Enabled . . . . : Yes
  IPv4 Address. . . . . . . . . . . : 10.0.200.6(Preferred)
  Subnet Mask . . . . . . . . . . . : 255.255.255.252
  Lease Obtained. . . . . . . . . . : Tuesday, May 27, 2014 10:19:14 AM
  Lease Expires . . . . . . . . . . : Wednesday, May 27, 2015 10:19:14 AM
  Default Gateway . . . . . . . . . :
  DHCP Server . . . . . . . . . . . : 10.0.200.5
  DNS Servers . . . . . . . . . . . : 192.168.1.253
                                      192.168.1.253
                                      192.168.1.253
  NetBIOS over Tcpip. . . . . . . . : Enabled

Now watching dns queries with wireshark - I only see dns queries to my pfsense box down the vpn.. Nothing going local at all.

Ok something is weird, I disconnected and connected again and now its only sending queries to my local dns - but down the gateway..  I don't have dns on my local segment to test that scenario.  Windows can do some odd shit for sure..  In this scenario you would be good because the queries would just go nowhere down your tunnel to those addresses..  If your worried about dns leakage, I would prob use a proxy on your vpn side and set your browser to use that proxy and setup in firefox for example the socks dns setting.

[NOYB]

Pippin, Maybe this would be a better place to continue the "block-outside-dns" discussion from https://forum.pfsense.org/index.php?topic=110910.0
https://forum.pfsense.org/index.php?topic=110910.msg617893#msg617893

So verb 4 shows the logs as you have too.  So my only issue with this is that it eliminates resolution of local names.  Need those some places.

[johnpoz]

continue??  this thread was from 2014 ;)

[Pippin]

Hmm, ok I see, the difference is that I'm not in a road worrier situation.
Connecting from home to my external server (NAS) which runs (adblocking) DNS and I can still talk to local.

Maybe ask over at OpenVPN Community Forum or even better on the users mailing list?

[johnpoz]

"Connecting from home to my external server"

How is that not a road warrior connection??  You don't have a site to site setup do you?  If its not site to site then your road warrior.

[Pippin]

I mean as in local is my home and my home is not switching networks  :)

[NOYB]

@johnpoz:

continue??  this thread was from 2014 ;)

Continuing from the other thread that we had hijacked.
Yes this thread is from 2014.  Is my thread that I started on the specific subject of local vs. VPN DNS name resolution, or more concisely put "DNS leakage", and previously there had not been a solid resolution to the issue.  So it is a very direct fit for the newly implemented "block-outside-dns" option discussion.