ANSWERED Win7 - DNS outside tunnel *only when VPN is connecting* (not usual DNS leak)

[duemo 0]

Hello,

 

I'm using AirVPN client on Windows 7. I've been looking at my outgoing traffic in my firewall logs to see if anything is being sent outside of the VPN by accident. I'm happy that the VPN tunnel is not leaking my DNS requests, as I do not see these on my firewall logs, or when I packet sniff my computer - everything is inside the encrypted tunnel.

 

However, at the start of the day, when my VPN is first establishing the tunnel, I notice that there are always logs in my firewall for a handful (five-ish) of DNS requests being sent from my PC to 10.4.0.1. This must be outside of the tunnel, because my firewall can see them. I haven't managed to capture any by packet sniff yet, to see exactly what they are.

 

What is causing this - some kind of checking by the client?

 

Thanks!

[zhang888 1065]

10.4.0.1 belongs to the RFC1918 group of private IP addresses for internal networks.

This means you simply cannot send anything to such address outside the tunnel - it will not

be routed outside your LAN.

[Guest]

In other words the 10.4.0.1 is the internal VPN address used for DNS if I'm not mistaken, you get assigned 10.4.0.12 or so when connecting so the VPN knows where to send the traffic to.

 

10.4.0.1 belongs to the RFC1918 group of private IP addresses for internal networks.

This means you simply cannot send anything to such address outside the tunnel - it will not

be routed outside your LAN.

[duemo 0]

Thanks guys. I'm aware that 10.4.0.1 is the DNS server address that I would normally query through the tunnel, and how private addressing works, so I understand that these DNS requests won't get past my firewall onto the Internet. However, I'd like to understand *why* my PC is sending them.

 

While typing this response, I actually managed to capture the requests in Wireshark, and saw that they are for "dns.msftncsi.com". Google seems to have explained, thought I would post for future reference in case others stumble across this: http://www.techrepublic.com/blog/data-center/what-do-microsoft-and-ncsi-have-in-common/

[airvpnpio 0]

10.4.0.1 belongs to the RFC1918 group of private IP addresses for internal networks.

This means you simply cannot send anything to such address outside the tunnel - it will not

be routed outside your LAN.

 

Same here with a Windows 7 virtual machine + "AEP tunnel" VPN software. This problem should not be confused with a more common issue where the OS is sending DNS requests to both inside and outside of the VPN tunnel. That in itself is sometimes considered a problem, but it is not a flaw of the VPN implementation itself.

 

In this case, the Windows 7 virtual machine is sending packets which should stay within the VPN tunnel, outside of the tunnel. I.e. the local network range is 192.168.12.0/12 and the VPN network range is 10.0.0.0/9.

 

Eventhough all IP traffic within 10.0.0.0/9 should stay within the VPN tunnel, I am capturing packets with WireShark that show that Windows 7 is sending DNS traffic for 10.58.x.x (the correct address of the DNS server) outside of the tunnel, with the (correct) L2 / MAC address of my 192.168.12.1 gateway.

 

According to the IP routing table (which I checked) this packet should never leave the Windows 7!

 

Now, depending on your setup, the traffic for 10.4.0.1 is either within or outside of the network ranges for which the VPN tunnel handles the traffic. Please could you check? What is the output of "netstat -nr" (cmd.exe)?

[Staff 9761]

Hello,

 

we don't understand what the posters are trying to say, so let's fix all the fundamental errors in an attempt to have a background with correct information.

 

the VPN network range is 10.0.0.0/9

 

The VPN subnet(s) is/are not and has/have never been 10.0.0.0/9. Please see https://airvpn.org/specs
 

Eventhough all IP traffic within 10.0.0.0/9 should stay within the VPN tunnel

 

This is not true. In addition to the above error, even if the specified subnet was correct (and it is not), the sentence appears to assume a flawed definition of "tunnel" which hints to a basic misunderstanding on how traffic is routed. The "tunnel" is defined by the routing table and the default gateway, not the other way round.

 

Windows 7 is sending DNS traffic for 10.58.x.x (the correct address of the DNS server)

 

10.58.x.x is not the IP address of any VPN DNS server and is not even within any subnet of the virtual networks.
 

DNS requests being sent from my PC to 10.4.0.1. This must be outside of the tunnel, because my firewall can see them

 

This is fine. A packet inspection tool inside your system can of course see traffic to/from the VPN while it has not yet been encrypted, or when it has been decrypted. When the packets are in the physical network interface of the system connected to a VPN server, they are encrypted, but on the tun/tap interface they are not, so you see them already/still unencrypted while they are in the tun interface.

 

Kind regards

[duemo 0]

...

 

I (duemo) have removed the rest of this post, as it is Staff's reply to somebody else.

 

...

 

 

DNS requests being sent from my PC to 10.4.0.1. This must be outside of the tunnel, because my firewall can see them

 

This is fine. A packet inspection tool inside your system can of course see traffic to/from the VPN while it has not yet been encrypted, or when it has been decrypted. When the packets are in the physical network interface of the system connected to a VPN server, they are encrypted, but on the tun/tap interface they are not, so you see them already/still unencrypted while they are in the tun interface.

 

Kind regards

 

Hi Staff - as you say, if it was only a packet sniffer on my PC that could see them, that would be ok. But my firewall can see these requests unencrypted, and my firewall is a completely different physical system to my PC, with multiple routers and switches separating the two. So the requests are definitely being sent outside the VPN tunnel.

 

Don't worry, I guess they are being sent outside the tunnel due to Windows 7's behavior, not a problem with AirVPN's software. I was really wondering why the requests are sent at all (whether it's from Windows or the AirVPN client), and not wondering why they are sent outside the tunnel. As per my last post, I believe I have found the cause.

 

Thanks!

[Staff 9761]

 

...

 

I (duemo) have removed the rest of this post, as it is Staff's reply to somebody else.

 

...

 

DNS requests being sent from my PC to 10.4.0.1. This must be outside of the tunnel, because my firewall can see them

 

This is fine. A packet inspection tool inside your system can of course see traffic to/from the VPN while it has not yet been encrypted, or when it has been decrypted. When the packets are in the physical network interface of the system connected to a VPN server, they are encrypted, but on the tun/tap interface they are not, so you see them already/still unencrypted while they are in the tun interface.

 

Kind regards

 

 

Hi Staff - as you say, if it was only a packet sniffer on my PC that could see them, that would be ok. But my firewall can see these requests unencrypted, and my firewall is a completely different physical system to my PC, with multiple routers and switches separating the two. So the requests are definitely being sent outside the VPN tunnel.

 

 

 

Hello,

 

surely the firewall is inside your LAN. That's perfectly normal (in Windows) due to the incorrect DNS implementation in this system. Note that 10.4.0.1 is set as primary DNS in every network interface (by Eddie), this is the explanation of what you observe, as already Zhang888 pointed out.

 

Next release might handle differently this issue (with ValdikSS integration in the main OpenVPN branch of the directive fixing DNS leaks in Windows, or by setting a totally unroutable address in the network interface instead of the VPN DNS), but it's not so serious. An adversary that wants to attack you with DNS poisoning in a public hot-spot (in which the attacker controls the router/hot-spot and sends you wrong resolutions of queries leaked inside the local network) should know in advance that you would be sending inside the LAN DNS queries to 10.4.0.1 (which is also the VPN gateway, making other DNS-based attacks impossible).

 

In the meantime just enable Network Lock and you will be protected even against this unlikely attack scenario.

 

EDIT: an overview of the wrong DNS implementation in various Windows versions and the implications for users of a VPN is here:

https://medium.com/@ValdikSS/beware-of-windows-10-dns-resolver-and-dns-leaks-5bc5bfb4e3f1

 

Kind regards

[airvpnpio 0]

While typing this response, I actually managed to capture the requests in Wireshark, and saw that they are for "dns.msftncsi.com". Google seems to have explained, thought I would post for future reference in case others stumble across this: http://www.techrepublic.com/blog/data-center/what-do-microsoft-and-ncsi-have-in-common/

 

That explains the nature of the packets that you captured in Wireshark, not why the traffic is visible outside of the VPN tunnel.

[airvpnpio 0]

Hello,

 

we don't understand what the posters are trying to say, so let's fix all the fundamental errors in an attempt to have a background with correct information.

 

 

the VPN network range is 10.0.0.0/9

The VPN subnet(s) is/are not and has/have never been 10.0.0.0/9. Please see https://airvpn.org/specs

 

 

Eventhough all IP traffic within 10.0.0.0/9 should stay within the VPN tunnel

This is not true. In addition to the above error, even if the specified subnet was correct (and it is not), the sentence appears to assume a flawed definition of "tunnel" which hints to a basic misunderstanding on how traffic is routed. The "tunnel" is defined by the routing table and the default gateway, not the other way round.

 

Windows 7 is sending DNS traffic for 10.58.x.x (the correct address of the DNS server)

 

10.58.x.x is not the IP address of any VPN DNS server and is not even within any subnet of the virtual networks.

 

>

DNS requests being sent from my PC to 10.4.0.1. This must be outside of the tunnel, because my firewall can see them

 

This is fine. A packet inspection tool inside your system can of course see traffic to/from the VPN while it has not yet been encrypted, or when it has been decrypted. When the packets are in the physical network interface of the system connected to a VPN server, they are encrypted, but on the tun/tap interface they are not, so you see them already/still unencrypted while they are in the tun interface.

 

Kind regards

 

Thanks for such an elaborate response!

 

In my example I was not referring to a setup that has anything to do with airvpn.org and your VPN services in particular. I was referring to another setup (with a customer) where Windows 7 is leaking DNS packets outside of the VPN tunnel. My apologies, as a guest on your forum I should have made this very clear in my first post.

 

 

In my particular example, the VPN client is running from within the Windows 7 virtual machine, and WireShark is running on the virtualization host, not the guest. So seeing packets with a 10.58.x.x destination address - outside of the VPN tunnel - is not ok. It would be ok if the routing table on the guest was wrong, but the routing table is fine, the traffic is being sent to the wrong gateway.

 

Eventhough my setup is not related to the services of airvpn.org, the similarity of my issue and that of "duemo", adds weight to the suspicion of a bug in Windows 7.

[duemo 0]

 

While typing this response, I actually managed to capture the requests in Wireshark, and saw that they are for "dns.msftncsi.com". Google seems to have explained, thought I would post for future reference in case others stumble across this: http://www.techrepublic.com/blog/data-center/what-do-microsoft-and-ncsi-have-in-common/

 

That explains the nature of the packets that you captured in Wireshark, not why the traffic is visible outside of the VPN tunnel.

 

As stated three times in this thread before you posted, I was trying to figure out the nature of the packets, not why they are visible outside the tunnel.

[airvpnpio 0]

As stated three times in this thread before you posted, I was trying to figure out the nature of the packets, not why they are visible outside the tunnel.

 

Hopefully my comments will be of value to others when they stumble upon this thread with title "Win7 - DNS outside tunnel *only when VPN is connecting* (not usual DNS leak)". Your postings were valuable to me because they refer to the same anomalies that I have seen. Thanks.