Misunderstandings about VPN's & DNS

Discussion in 'privacy technology' started by AnotherBob, Jan 5, 2015.

  1. AnotherBob

    AnotherBob Registered Member

    Joined:
    Jan 5, 2015
    Posts:
    5
    Hello,

    I wanted to pose a scenario to the folks here on this forum and get feedback on various ways the experts here go about avoiding this potential trap. My apologies in advance for the length of this post but these are questions I just have not been able to find reliable answer to elsewhere.

    Throughout my travels on the Internet I have seen many questions posted about how to properly set up VPN's on the endless flavours of routers and client OS's. During the set up process one question that comes up allot is how to handle DNS queries while actively connected to "insert your favourite VPN provider here" secured tunnel.

    Based on my understanding of how DNS works is that ideally you would want your DNS queries to be sent THRU the vpn tunnel and handled by the VPN providers DNS servers so that once the web page is returned it takes the same return path back THRU the VPN tunnel to your web browser for secure viewing of whatever content you requested.

    Assuming the above statement is true for most people of these VPN services then it appears there are many ways folks can shoot themselves in the foot during the router configuration process which could easily jeopardize the added anonymity provided by using a VPN service in the first place.

    Lets take a popular router as an example. Say the User is using an Asus RT-AC66U that runs the popular Tomato Shibby firmware ver 1.28. If said User goes thru the steps to configure a VPN connection and chooses to "Exclusively" accept the DNS configuration of the VPN provider while the tunnel is UP, in theory, all of their DNS requests should go thru the tunnel and be returned using the same path. BUT, here's the rub......

    If for example the user configuring the router also chooses to configure DNSCrypt it would seem they have just successfully shot themselves in the foot based on the behaviour of DNS queries after doing so. By this I mean, it seems they have just introduced a DNSLeak and a second Non-VPN provided return path for DNS queries to take. During some testing I was able to confirm this by checking one of the popular DNSLeak test sites. The test showed X 2 DNS providers. One being the VPN DNS server and the second being the DNSCrypt DNS server.

    So, the real issue I see here is that it appears that the DNSCrypt DNS server is using your real ISP provided public IP Address as the source of the DNS query so this would mean that it has no choice but to return the web page content back to the original source IP where the request came from outside the tunnel in an unencrypted manor. Obviously this is not an ideal scenario and can easily mislead/fool the less savy into thinking they are still safely viewing content under the umbrella of the VPN provider tunnel.

    So a few questions come to mind here:

    1. Is there a way to force DNSCrypt thru the VPN tunnel instead of having it work outside on its own? (IP Tables or Firewall Policy Maybe?) It appears that once DNSCrypt is enabled it basically wants to take over and intercept all DNS queries and send them out directly to the DNSCrypt target server and in doing so it ignores any previously pushed DNS servers provided by the VPN tunnel. It also appears to have a higher priority in the pecking order as well so its not likely any other servers being pushed will ever get used before DNSCrypt would.

    As a side note, it seems like there could be a good reason why someone would want to use both DNSCrypt and the VPN tunnel together. One reason that comes to mind would be someone not wanting to put all their eggs in one basket so to speak. By this I mean, maybe using both would disassociate the search history from the content being delivered? While it would be nice to 100% believe these VPN providers are not keeping logs despite saying so I'm personally not convinced this is the case yet. If the "MAN" comes knocking one day at the VPN providers door he has both search history and content all in one shot. If one could use DNSCrypt tunnelled thu a VPN would this offer any added denyability?

    2. Is there a way to Lower the Priority of DNSCrypt in the DNS server pecking order on a Tomato router which would also allow it to keep running in the background? An ideal scenario would be one that allows a choice of which clients on the LAN use DNSCrypt by way of an IP Table Policy of some sort.

    I'm using IP Table policies now for PREROUTING & Tagging certain source IP's to either USE or NOT USE the VPN. It would be a beautiful thing to add to that what DNS server these clients will choose as their Primary. One would think that a client being specificity told to use the VPN via a PREROUTING policy would not attempt to use the DNSCrypt-Proxy settings but due to the Priority of DNSCrypt it seems to take over anyway.

    Thanks for reading and please let me know your thoughts on this
     
  2. AnotherBob

    AnotherBob Registered Member

    Joined:
    Jan 5, 2015
    Posts:
    5
    OK...200+ views and no responses :eek:

    Maybe I have gone mad :doubt:
     
  3. navigat0r

    navigat0r Registered Member

    Joined:
    Jan 8, 2015
    Posts:
    26
    Are you sure that dnscrypt does not use the tunnel on tomato?
    You can verify this by running tcpdump on your physical wan interface:
    tcpdump -Sv -i <interface> host not <vpn server ip>
    On OpenWrt, dnscrypt queries are routed through tunnel.
     
  4. AnotherBob

    AnotherBob Registered Member

    Joined:
    Jan 5, 2015
    Posts:
    5
    For clarity purposes, I was referring to using the built-in DNSCrypt option found on the Tomato router. In that configuration outbound DNS queries did not appear to be using the VPN tunnel.

    This can be confirmed when viewing the dnsmasq.conf file after DNSCrypt is enabled on Tomato. A single "server" entry is then added with the following:

    server=127.0.0.1#40

    I believe for now I have found a workaround for this though.

    If I move the DNSCrypt duties off of the Tomato router (ie..not enable it) and instead install DNSCrypt on a client PC who is being directed to use the VPN tunnel exclusively via IPTable rules the client will then pipe the DNS queries out thru the VPN tunnel to the to the DNSCrypt resolver.

    At some point I will muster enough motivation to hookup a laptop upstream of the WAN port of the Tomato router were it feeds into my firewalls Inside Interface so I can sniff around more thoroughly. I may need to configure a SPAN port on the firewall so I can capture all the traffic on the Inside Interface and send it to a Wireshark log. It seems the built in logging on the Cisco ASA, even in Debug mode, is not granular enough for this purpose thus the reason for wanting to use Wireshark instead.
     
  5. navigat0r

    navigat0r Registered Member

    Joined:
    Jan 8, 2015
    Posts:
    26
    From https://github.com/opendns/dnscrypt-proxy#using-dnscrypt-in-combination-with-a-dns-cache

    "The DNSCrypt proxy is not a DNS cache. This means that incoming queries will not be cached and every single query will require a round-trip to the upstream resolver.

    For optimal performance, the recommended way of running DNSCrypt is to run it as a forwarder for a local DNS cache [...]"

    I assume it's also the way how tomato uses DNSCrypt: dnsmasq serves as a cache for lan clients, and forwards new dns requests to DNSCrypt listening on 127.0.0.1:40. Probably dnsmasq is run with the option -R, --no-resolv (ignore /etc/resolv.conf) which makes sense if you want all dns queries to be made by DNSCrypt.

    In such a scenario it depends on the routing table of tomato whether DNSCrypt will use the tunnel or your ISP's connection. In most cases openvpn adds a default gateway via tun interface which means DNSCrypt has to use the vpn connection.
     
  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.