Network Lock DNS Leaks (with default settings)

[sir_trackmenot 4]

I noticed some concerning things on Ubuntu 16.04 with the portable Eddie (2.10.3).

 

When I enable NetworkLock I see that it doesn't block DNS. This means that if the VPN is down for any reason my ISP DNS is restored and there is a leak. I can demonstrate this with

pkill -9 openvpn ; dig some_domain_i_havent_previously_resolved.com

The name lookup completes before the VPN connection is restored. VPN DNS is restored shortly when the VPN auto-restarts.

 

Since I live in a country with legislated spying on its own citizens I do not want this, obviously, even if the window of risk is small.

 

I have also noticed it adds the following firewall rules by default:

    0     0 ACCEPT     all  --  *      *       0.0.0.0/0            255.255.255.255     
    5   291 ACCEPT     all  --  *      *       192.168.0.0/16       192.168.0.0/16      
   20  1292 ACCEPT     all  --  *      *       10.0.0.0/8           10.0.0.0/8          
    0     0 ACCEPT     all  --  *      *       172.16.0.0/12        172.16.0.0/12       

I don't think those are strictly necessary and definitely shouldn't be allowed by default, particularly when so many people where I live connect to mobile providers that provide 10/8 private addresses to clients.

 

I can work around both issues by turning off the 'Allow lan/private' setting in advanced, but I think it really should be off by default for maximum privacy.

[zhang888 1066]

What is the output of dig +trace example.com?

Then we should see which server, in order, replied this request.

If you have another DNS server in your /etc/resolv.conf, and it is on your LAN,

this might be the reason for your leak.

 

 

The 10/8 rule is on by default for usability. This is much easier for an advanced user to

disable it, rather that for a non-technical user to understand why his local shares became

inaccessible. There are many threads about this already.

Mobile carriers do assign 10/8s to customers, but those are firewalled and VLAN tagged

so you won't be able to reach other subscribers, unless they totally misconfigure something

but usually it's part of rolling up the network in the first place so it cannot go much wrong.

[Staff 9972]

I noticed some concerning things on Ubuntu 16.04 with the portable Eddie (2.10.3).

 

When I enable NetworkLock I see that it doesn't block DNS. This means that if the VPN is down for any reason my ISP DNS is restored and there is a leak. I can demonstrate this with

pkill -9 openvpn ; dig some_domain_i_havent_previously_resolved.com

The name lookup completes before the VPN connection is restored. VPN DNS is restored shortly when the VPN auto-restarts.

 

 

This is unexpected, unless you query a DNS server that's running inside your local network, for example in your router. In this case you can't blame Network Lock, it's a fault in your own configuration, because Network Lock purpose is ALLOWING anything from and to your router. Easily fixable anyway in a few seconds.

 

 

I have also noticed it adds the following firewall rules by default:

    0     0 ACCEPT     all  --  *      *       0.0.0.0/0            255.255.255.255     
    5   291 ACCEPT     all  --  *      *       192.168.0.0/16       192.168.0.0/16      
   20  1292 ACCEPT     all  --  *      *       10.0.0.0/8           10.0.0.0/8          
    0     0 ACCEPT     all  --  *      *       172.16.0.0/12        172.16.0.0/12       

I don't think those are strictly necessary and definitely shouldn't be allowed by default, particularly when so many people where I live connect to mobile providers that provide 10/8 private addresses to clients.

 

 

Those rules are applied ONLY if "Allow LAN/private" is ticked. It's a customer's free choice. Note: if "Allow LAN" is unticked, Network Lock will anyway allow communications to your router/upstream device, and DHCP negotiations, obviously. How to set the default setting is a difficult choice involving software design so we based the choice on the feedback we have received during years and an overwhelming majority of users want this option enabled.

 

Please see here for further details:

https://airvpn.org/faq/software_lock/

 

Kind regards

[iwih2gk 93]

I noticed some concerning things on Ubuntu 16.04 with the portable Eddie (2.10.3).

 

When I enable NetworkLock I see that it doesn't block DNS. This means that if the VPN is down for any reason my ISP DNS is restored and there is a leak. I can demonstrate this with

pkill -9 openvpn ; dig some_domain_i_havent_previously_resolved.com

The name lookup completes before the VPN connection is restored. VPN DNS is restored shortly when the VPN auto-restarts.

 

Since I live in a country with legislated spying on its own citizens I do not want this, obviously, even if the window of risk is small.

 

I have also noticed it adds the following firewall rules by default:

    0     0 ACCEPT     all  --  *      *       0.0.0.0/0            255.255.255.255     
    5   291 ACCEPT     all  --  *      *       192.168.0.0/16       192.168.0.0/16      
   20  1292 ACCEPT     all  --  *      *       10.0.0.0/8           10.0.0.0/8          
    0     0 ACCEPT     all  --  *      *       172.16.0.0/12        172.16.0.0/12       

I don't think those are strictly necessary and definitely shouldn't be allowed by default, particularly when so many people where I live connect to mobile providers that provide 10/8 private addresses to clients.

 

I can work around both issues by turning off the 'Allow lan/private' setting in advanced, but I think it really should be off by default for maximum privacy.

 

 

You also have another easy and sure fire solution:  apply a simple ufw rule that limits traffic to tun0 on your mint system.  You would enable ufw containing that one rule AFTER connecting with Eddie.  If the connection breaks you are dead in the water until you manually drop ufw to allow Air to reconnet (or any internet traffic at all).  Disclaimer; this will also keep your machine away from LAN devices unless you add other rules to allow those in.  I don't, and never will!

[sir_trackmenot 4]

What is the output of dig +trace example.com?

 

I don't have access to that machine currently so I can't test that. I can attest from the DNS logs on my router that the requests are definitely making it to the local network router.

 

Then we should see which server, in order, replied this request.

If you have another DNS server in your /etc/resolv.conf, and it is on your LAN,

this might be the reason for your leak.

 

Yes. Like most users, the DNS server that is configured by DHCP is on the local LAN. It is this way because it is necessary in our setup. It is this way for must users because their shitty home router has a DNS cache for performance reasons.

 

This is the network setup that the average home user actually has, and Eddie allows a leak in this setup.

 

The 10/8 rule is on by default for usability. This is much easier for an advanced user to

disable it, rather that for a non-technical user to understand why his local shares became

inaccessible. There are many threads about this already.

 

The non-technical user doesn't know, nor care about "local shares" on their network. Their idea of the Internet is "put my computer on wifi". Technical users can enable local routing if they need it.

 

Follow the principle of least surprise:

 

A user turns on the "Network Lock" feature, which is documented to prevent any traffic leaving except over the VPN. By default, the feature doesn't do that - it punches holes into the firewall that allow leaks. The default privacy settings of the Network Lock feature actually result in potential leaks that the average non-technical user wouldn't know existed or think to check for and close.

 

Mobile carriers do assign 10/8s to customers, but those are firewalled and VLAN tagged

so you won't be able to reach other subscribers, unless they totally misconfigure something

but usually it's part of rolling up the network in the first place so it cannot go much wrong.

 

I couldn't care less about talking to other clients on the mobile carrier's network. I care about talking to resources that they provide inside that network like DNS and a number of transparently proxied services (NTP, etc). My mobile carrier transparently proxies DNS, for example.

 

In a country where everything must be logged by the carrier and supplied to government and certain corporate goons for analysis (and I'm supposedly in a "free" first-world country) a single leak outside the VPN could spell disaster - specially if that DNS leak was for something they're specifically targeting with their spy laws (the pirate bay or wikileaks, for example). Users in a less free countries could have their life put at risk by these leaks.

 

The VPN connection can, and does, drop out while it is actively used. With VPN being acknowledged as a way around the spying I see government goons working to interrupt connections to achieve just these kind of leaks.

 

Please fix the network lock feature to block *everything* by default. I have worked around the issue, but the average non-technical user will be caught out by its ineffectiveness.

[sir_trackmenot 4]

Another issue is that if DHCP on the network interface re-issues an address the resolv.conf file may be overwritten with an unsafe DNS server while the VPN is still active.

 

If punch through for local LAN is enabled this can result in DNS leaks even while the VPN is up. That's pretty bad.

[zhang888 1066]

Your solution would be simply not using the router's DNS server in your network adapter.

Blocking all traffic to all LAN segments will break the essential connectivity protocols (DHCP,DNS) and

will lock the user even outside his local network and inevitably the router.

 

A user turns on the "Network Lock" feature, which is documented to prevent any traffic leaving except over the VPN. By default, the feature doesn't do that - it punches holes into the firewall that allow leaks. The default privacy settings of the Network Lock feature actually result in potential leaks that the average non-technical user wouldn't know existed or think to check for and close.

 

Please read the documentation in full

The section below describes your previous setup, and reminds you that there are other things that you can configure:

 

You can also decide whether to allow LAN and/or ping or not by ticking or un-ticking "Allow lan/private" and "Allow ping".

 

The "feature" you proposed will result in broken connectivity from the moment you activate it, unless static IPs are used.

This is not an expected (default) behavior in any case, since the problem you describe is much easier

to solve from your side. This would also be a more complete and elegant solution.

[sir_trackmenot 4]

Your solution would be simply not using the router's DNS server in your network adapter.

 

Try explaining that to my parents, or my aunt, or the lawyer around the corner who use their computer to get work done and nothing more. They haven't a clue what DNS is, let-alone how to configure it.

 

Blocking all traffic to all LAN segments will break the essential connectivity protocols (DHCP,DNS) and

will lock the user even outside his local network and inevitably the router.

 

It would not, because you can allow DHCP (UDP 67,68) for interfaces that require it without requiring all broadcast or local traffic to be allowed on the interface. "Essential" DNS is exactly what I'm complaining about, because it turns out it's not all that essential to the functioning of Eddie - you can include lists of IP addresses and update them through the API when a successful VPN connection is established.

 

 

A user turns on the "Network Lock" feature, which is documented to prevent any traffic leaving except over the VPN. By default, the feature doesn't do that - it punches holes into the firewall that allow leaks. The default privacy settings of the Network Lock feature actually result in potential leaks that the average non-technical user wouldn't know existed or think to check for and close.

 

Please read the documentation in full

The section below describes your previous setup, and reminds you that there are other things that you can configure:

 

You can also decide whether to allow LAN and/or ping or not by ticking or un-ticking "Allow lan/private" and "Allow ping".

 

The "feature" you proposed will result in broken connectivity from the moment you activate it, unless static IPs are used.

This is not an expected (default) behavior in any case, since the problem you describe is much easier

to solve from your side. This would also be a more complete and elegant solution.

 

I have read the documentation. It glosses over that allowing traffic to the local network could result in leaks, even if the local network is trusted.

 

I disagree with the defaults. The defaults are dangerous and unexpected and will cause harm for non-technical users who don't understand what's going on.

 

Expected and secure: block everything and punch through the bare minimum to get what you need working (i.e. UDP 67/68 to the broadcast address for DHCP on interfaces that require it). Configuration option to allow more than that for users who know what they are doing.

 

Surprising and insecure: block most things but punch through huge blocks of IP addresses just in case users are confused by local resources becoming non-functional. Configuration option to become secure.

[go558a83nk 362]

 

Your solution would be simply not using the router's DNS server in your network adapter.

 

Try explaining that to my parents, or my aunt, or the lawyer around the corner who use their computer to get work done and nothing more. They haven't a clue what DNS is, let-alone how to configure it.

 

>Blocking all traffic to all LAN segments will break the essential connectivity protocols (DHCP,DNS) and

will lock the user even outside his local network and inevitably the router.

 

It would not, because you can allow DHCP (UDP 67,68) for interfaces that require it without requiring all broadcast or local traffic to be allowed on the interface. "Essential" DNS is exactly what I'm complaining about, because it turns out it's not all that essential to the functioning of Eddie - you can include lists of IP addresses and update them through the API when a successful VPN connection is established.

 

 

A user turns on the "Network Lock" feature, which is documented to prevent any traffic leaving except over the VPN. By default, the feature doesn't do that - it punches holes into the firewall that allow leaks. The default privacy settings of the Network Lock feature actually result in potential leaks that the average non-technical user wouldn't know existed or think to check for and close.

 

Please read the documentation in full

The section below describes your previous setup, and reminds you that there are other things that you can configure:

 

You can also decide whether to allow LAN and/or ping or not by ticking or un-ticking "Allow lan/private" and "Allow ping".

 

The "feature" you proposed will result in broken connectivity from the moment you activate it, unless static IPs are used.

This is not an expected (default) behavior in any case, since the problem you describe is much easier

to solve from your side. This would also be a more complete and elegant solution.

 

I have read the documentation. It glosses over that allowing traffic to the local network could result in leaks, even if the local network is trusted.

 

I disagree with the defaults. The defaults are dangerous and unexpected and will cause harm for non-technical users who don't understand what's going on.

 

Expected and secure: block everything and punch through the bare minimum to get what you need working (i.e. UDP 67/68 to the broadcast address for DHCP on interfaces that require it). Configuration option to allow more than that for users who know what they are doing.

 

Surprising and insecure: block most things but punch through huge blocks of IP addresses just in case users are confused by local resources becoming non-functional. Configuration option to become secure.

 

 

You obviously haven't read the number of posts here of people complaining that local resources were unavailable...because of network lock.

 

The prudent thing to do is get things working and as safe as possible for the average person and let the power user make tweaks if they want.

 

If network lock was as you desire Air would have many people leaving for another VPN provider because in their mind it "didn't work".