Stop AirVPN from automatically registering its internal IP in local DNS

[Festus Heinhold 3]

AirVPN's virtual NIC, when viewed in Windows' Network Connections screen, has the following checkbox set:

"Register this connection's address in DNS"

This is troublesome because by having this option set, the internal address of the AirVPN NIC is pushed to the local domain's DNS server. For a number of reasons I won't detail here, I'd prefer that not to be the case.

Unchecking the box doesn't work. As soon as AirVPN connects again, it reverts the settings for this NIC on its own such that the box is rechecked.

The only workaround I've found thus far is to manually connect to AirVPN, enter the NIC properties, and manually uncheck the box. This causes the AirVPN NIC's internal IP to be removed from the DNS Server -- which is what I want. 

But the DNS settings never "stick." The next time I connect to AirVPN, the option is re-selected. Any way around this?

[Staff 9973]

Quote

This is troublesome because by having this option set, the internal address of the AirVPN NIC is pushed to the local domain's DNS server. For a number of reasons I won't detail here, I'd prefer that not to be the case.

It's a security feature.

When the DNS IP address matches the VPN gateway IP address the notorious attack based on DNS hijacking and route injection, which most commercial VPNs are vulnerable to, becomes impossible.
https://www.researchgate.net/publication/274800185_A_Glance_through_the_VPN_Looking_Glass_IPv6_Leakage_and_DNS_Hijacking_in_Commercial_VPN_clients

Note that the paper cites AirVPN, but that's a paramount error, as the researchers did not fix the paper, not even after we repeatedly warned them about their mistake.

We are not aware of any negative consequence, please feel free to elaborate.

You are anyway free to query 10.4.0.1 in case you don't like the security feature for any reason. Address 10.4.0.1 is reachable by DNS queries from any VPN subnet.

Kind regards
 

[Festus Heinhold 3]

9 hours ago, Staff said:

We are not aware of any negative consequence, please feel free to elaborate.
 

Shifting the local DNS setting when connected to AirVPN isn't a problem. That part totally makes sense. The problem is that AirVPN registers its own internal IP address in the domain controller's DNS.

Consider a machine named inst6. It has an IP address of 10.0.1.175. It's a member of a domain, so when it boots up, it properly registers inst6 as having an IP address of 10.0.1.175 in the domain controller's DNS service. Pretty standard so far.

Now I fire up AirVPN and connect to server. By doing so, I now have an additional IP address of 10.8.154.85. That new address is bound to AirVPN's virtual NIC. Again, nothing unusual about that.

But because AirVPN keeps forcing that virtual NIC to register with my domain controller's DNS, our local DNS now has *two* IP addresses registered from inst6: 10.0.1.175 (the original one) and 10.8.154.85 (the AirVPN-assigned one).

This causes problems when other machines on the LAN want to talk to inst6, since the local DNS server will resolve inst6 to 10.0.1.175 (good) sometimes and 10.8.154.85 (bad) at other times. The former address is reachable but the latter obviously is not. This makes inst6 unreachable half the time.

My Solution: By manually deselecting the "Register this connection's address in DNS" checkbox for the AirVPN NIC, the AirVPN address won't be submitted to the local DNS server and the reachability problem goes away. All other LAN members will resolve inst6 to it's true address of 10.0.1.175.

The problem: AirVPN overwrites my settings the next time it connects, effectively re-checking this checkbox that I deselected. This forces me to go through this same 'uncheck the checkbox' routine each and every time I connect to AirVPN.

My goal is to make inst6 reachable to trusted LAN members but disguise its IP when communicating with Internet hosts. This seems to be a use case that AirVPN desires to provide us, given the "allow lan/private" option that's made available to users. But this constant registration of an unreachable AirVPN IP into the local DNS throws a wrench into things. 

[Staff 9973]

3 hours ago, festus8888 said:

But because AirVPN keeps forcing that virtual NIC to register with my domain controller's DNS, our local DNS now has *two* IP addresses registered from inst6: 10.0.1.175 (the original one) and 10.8.154.85 (the AirVPN-assigned one).

 

In this case the "problem" does not exist, as what you define as "forcing" is in reality an ordinary DNS push performed by the VPN server. DNS push informs your system what IP address the DNS server has in the virtual network (if any) but does not force it.

OpenVPN client for BSD and Linux systems by default ignores the DNS push, while OpenVPN for Windows accepts it. Eddie by default accepts it (on all supported systems), but you can tell it not to do it in "Preferences" > "DNS" > "DNS Switch Mode" (when you disable the switch, remember to untick "Check Air VPN DNS", otherwise Eddie will correctly check the DNS usage and throw an error, and set your favorite DNS server address(es) in "DNS Servers" field).

You have total freedom about how to handle the DNS push: it's an optional, not a forced feature. Enjoy AirVPN!

Kind regards
 

[Flx 76]

On 8/9/2019 at 6:52 PM, festus8888 said:

But the DNS settings never "stick." The next time I connect to AirVPN, the option is re-selected. Any way around this?

Option1.

netsh int ipv4 add address "tapadaptername" address= 10.8.154.85 mask=255.255.255.0 skipassource=true

Option2.

Separate home/lan from virtual adapters;In other words "segmenting" your network:

https://airvpn.org/forums/topic/17440-guide-fix-for-tap-adapter-in-windows/?do=findComment&comment=77188


 

[Flx 76]

On 8/10/2019 at 12:58 PM, festus8888 said:

My Solution: By manually deselecting the "Register this connection's address in DNS" checkbox for the AirVPN NIC, the AirVPN address won't be submitted to the local DNS server and the reachability problem goes away. All other LAN members will resolve inst6 to it's true address of 10.0.1.175.

Your solution does not work, If you do this through GUI.
Regards,
Flx