IPv6 & AirVPN (on Linux): Please reconsider your approach

[Stalinium 44]

Currently AirVPN servers ONLY provide you with IPv6 connectivity (IPv6 traffic via VPN) if OpenVPN correctly pushes a certain value to the server. This is what the relevant config lines look like:

push-peer-info
setenv UV_IPV6 yes

'UV_IPV6 yes' is a variable that is set to 'yes', basically: yes, gimme IPv6
push-peer-info sends the server information about the client. This includes: OS version and OpenVPN client release, your router's MAC address and of course the UV_IPV6 variable that tells the server to give you an IPv6 address.

This last part is problematic and has already led to problems for AirVPN users:
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/556
I've run into this issue myself when I tried to get AirVPN running on Linux using the NetworkManager interface (present in virtually every distro out there). It's confusing because it seems to work but in reality it doesn't. You do get a connection, except without IPv6 forwarding.
It's no surprise people encounter this: Why would one really need to install your client if the preinstalled GUI manager has worked fine before? Nobody knows the intricacies. Not even those who reported the issue to the correct place above!

*drum-roll* and the problem is: NetworkManager.
Really. NetworkManager is crippled in that it DOES NOT support many of the OpenVPN features. The combination of push-peer-info + setenv is one of them.
The variable is not set upon connection -> VPN connects to the server -> The server does not see UV_IPV6=yes -> The server only setups IPv4 for the client.

Yes, THIS IS A SECURITY ISSUE.
According to Google, 32% of users have IPv6. Here come you, an AirVPN user with IPv4 and IPv6 on Linux, using NetworkManager. It seems to connect. You quickly check a website to see your IP and see that you indeed got a new IP (IPv4) after connecting to the VPN. Maybe the website doesn't show IPv6 at all, or the user doesn't pay attention to the fact this long and cryptic IPv6 didn't change or maybe the user did not yet have IPv6 and it was enabled later by the ISP... And there the user goes to surf online with half his ass naked: IPv4 is properly routed through AirVPN but IPv6 is still going through his real ISP.

This must be changed.
IPv6 must be the default. Do not leave a chance to expose users.

When this change is applied, both config lines will be rendered obsolete and as a bonus, the clients will no longer unnecessarily send their internal MAC addresses to the server, which can be used too:

Quote

To do so, the FBI carried out a NIT, or network investigative technique, and bypassed Tor to gather IP addresses, MAC addresses, and other bits of information on the suspects.

- https://threatpost.com/fbi-mum-on-how-exactly-it-hacked-tor/117127/ | https://www.theregister.com/2018/02/24/tor_fbi_hacking_appeal/
 

Quote

It then abuses the SendARP() function, which is usually used for discovering the MAC addresses of other computers to find our MAC address instead. There are ‘proper’ ways to do this, but given the limited space available to shellcode this achieves the job. The MAC address will tie the user to a particular network card, which they may be able to trace through the supply chain.

- https://web.archive.org/web/20180923231303/https://blog.owenson.me/analysis-of-the-fbi-tor-malware/

Finally if you feel there's someone who really wishes to not use IPv6 via Air: reverse the config. Make it an explicit UV_IPV6=no to opt-out.
Security must be the default. Thanks for reading. I really hope this change to be introduced soon.

PS: Can someone login at the Freedesktop bug tracker above to tell these people that it's fixable? I don't have an account
PPS: You can see what push-peer-info sends if you set verbosity to 4: "verb 4" in the config
Tags: IPv6 not working AirVPN Linux config openvpn

[Staff 9971]

@Stalinium
 

Quote

This last part is problematic and has already led to problems for AirVPN users:
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/556
I've run into this issue myself when I tried to get AirVPN running on Linux using the NetworkManager interface (present in virtually every distro out there).

Hello!

Maybe you talk about network-manager-openvpn plugin, as network-manager by itself does not support OpenVPN. In our configuration files the directives to cause IPv6 push are included, unless you specifically tell the CG to NOT route IPv6 over IPv4.

It's not our fault if they are ignored. On the other hand we have been deprecating usage of network-manager-openvpn since years and years ago for other critical problems. If you decide to use it in spite of our recommendations, you do it at your own risk.

You are not forced to run our software in Linux. You can run OpenVPN directly for example, or any other OpenVPN GUI/wrapper different than network-manager-openvpn. In this case, you will of course need by yourself to take care of DNS push and network lock, features that are handled automatically by all of our software for Linux.

It's therefore a security issue by network-manager-openvpn, not by AirVPN, because it's network-manager-openvpn that ignores directives that our Configuration Generator puts in, and it's you the one who does not replicate Network Lock which would have made the problem anyway irrelevant (under a security point of view).

 

Quote

 

Quote

the clients will no longer unnecessarily send their internal MAC addresses to the server, which can be used too:
To do so, the FBI carried out a NIT, or network investigative technique, and bypassed Tor to gather IP addresses, MAC addresses, and other bits of information on the suspects.

Quote

- https://threatpost.com/fbi-mum-on-how-exactly-it-hacked-tor/117127/ | https://www.theregister.com/2018/02/24/tor_fbi_hacking_appeal/

Nonsense, a MAC address is simply is not included in IPv4 packets (there's just no room for it), while nowadays all systems mitigate the MAC problem in IPv6 addresses. Our servers never receive the MAC address of any of your physical network interfaces of the router and even less of the computer. The problem is more basic, and it's simply having IPv6 traffic outside the VPN tunnel but keep in mind that you ignored instructions and our suggestions, up to the point to use exactly the software we tell you NOT to use.

About FBI... What FBI really did was something quite different and is not a Tor problem in itself (for Silk Road, for example, it was "only" social engineering, by infiltrating an agent in the core of Silk Road and exploiting administrator's trust in this infiltrated agent - in other cases it used javascript which the final user recklessly allowed execution of, on the browser, and in a Windows system) but anyway they are talking about Tor and not OpenVPN, so we can cut the FBI cracking techniques discussion here as it is irrelevant for the matter.

 

Quote

Finally if you feel there's someone who really wishes to not use IPv6 via Air: reverse the config. Make it an explicit UV_IPV6=no to opt-out.
Security must be the default. Thanks for reading. I really hope this change to be introduced soon.

Unfortunately not all OpenVPN versions, in client mode, can push a UV, and most versions which can't are the old ones which are also bugged with IPv6. The whole setup has been made with the purpose not to send IPv6 push to those OpenVPN versions which are bugged and would create critical errors with IPv6 push. This backward compatibility may be abandoned one day, but it's still not the right time.  Anyone having new versions can send UV and therefore this solution makes everyone happy. Furthermore our Network Lock includes IPv6 rules to prevent leaks.

Remember that VPN software is not designed to provide an anonymity layer. It's the environment we create with our software which makes it possible, and VPN connection is a part of the anonymity layer. If you renounce to part of this environment by not using our software, you must understand what you do and how to replicate various features, first and foremost Network Lock. If you use a software that, to make things even worse, negligently ignores our own CG directives, and it is furthermore deprecated by us, then you're running at your own risk, ça va sans dire.
.
Kind regards
 

[OpenSourcerer 1435]

I've been trying to use nm-openvpn in the past, twice. My biggest problem with it was that I couldn't configure the client to accept redirect-gateway def1, it always overrode the default gateway, so in essence I lost connectivity to my local network (because it did not parse any of the route directives as well!), except the router, of course. And this was on IPv4.

Staff, how feasible would it be to implement a DNS leak protection using NetworkManager profiles?

[Staff 9971]

@OpenSourcerer

Hello!

It must be seen how nm-ovpn handles DNS push. Historically, it has always been able to properly accept DNS push and then restore previous settings at the end of the connection. However, a double-check in those systems which run systemd-resolved configured in on-link mode and /etc/resolv.conf bypass (example: Fedora 33 by default settings) would be safer, you never know.

In other systems where the global DNS is preserved and nameservers are "decided" by /etc/resolv.conf it appears that nm-ovpn properly handles DNS push, no DNS leaks are possible.

A more general approach when you don't know which configuration you might encounter is (on top of usual network lock rules) blocking, via firewall, packets (both TCP and UDP) to port 53 of the router address, to prevent that local queries can be forwarded by the router in clear text to some other nameserver, potentially the ISP DNS server (it would not be a DNS leak, because the system does what you tell it to do, but the outcome is anyway a query out of the tunnel).

Kind regards
 

[Stalinium 44]

Thanks a lot for your elaborate response, I appreciate that! Sorry it took so long to answer...
Ah and yes with NM I obviously mean NetworkManager + its OpenVPN plugin.

On 5/27/2021 at 12:29 PM, Staff said:

On the other hand we have been deprecating usage of network-manager-openvpn since years and years ago for other critical problems. If you decide to use it in spite of our recommendations, you do it at your own risk.

After consideration it's indeed a not proper, but sane solution to just not use NM (OpenSourcerer's answer just highlights yet another issue). It's a shame it's practically default in all distros with such glaring issues.
Then I just wish you added a little banner to the config generator page warning the Linux users when Linux is chosen (and add a red * asterisk to "Linux*" so it's instantly apparent), linking the warning thread (I've missed it, just like the users from bug report): https://airvpn.org/forums/topic/11416-using-airvpn-with-debian-network-manager-not-recommended/

Forums are great, but just like with anything, finding the right information when needed is a problem sometimes. It's not like I intentionally ignored it just never found. Oh and while at it, the thread's topic can also be improved, it's not just Debian: Ubuntu, Manjaro, most likely other Debian-derivaties. As I said I think a warning banner will suffice.

All in all, I agree not least because of:

On 5/27/2021 at 12:29 PM, Staff said:

Unfortunately not all OpenVPN versions, in client mode, can push a UV, and most versions which can't are the old ones which are also bugged with IPv6.

---

On 5/27/2021 at 12:29 PM, Staff said:

Our servers never receive the MAC address of any of your physical network interfaces of the router and even less of the computer.

I should've been clearer as I forgot to explain why exactly and how (yes, I never meant the MAC in IP packets reaching the servers). The MAC is indeed sent to the server by OpenVPN, it's the MAC of the currently main "net_gateway" (where all your traffic passes through normally; the PC MAC address on LAN):
 

Quote

https://openvpn.net/community-resources/reference-manual-for-openvpn-2-4/
--push-peer-info
    Push additional information about the client to server. The following data is always pushed to the server:

https://openvpn.net/community-resources/reference-manual-for-openvpn-2-4/
--push-peer-info
    Push additional information about the client to server. The following data is always pushed to the server:

This is how https://airvpn.org/sessions/ is able to show the client/UI/OS versions.
Interestingly, iOS and Android are different, maybe even worse (depends on PoV):

Quote

https://openvpn.net/vpn-server-resources/access-server-post-auth-script-host-checking/#authentication-and-role-of-post_auth
An important thing to note here is that while Windows, Linux, and macOS devices will be reporting a MAC address, iOS and Android devices will not. This is due to the nature of privilege limitation and also some other design choices related to how mobile platforms work. For iOS and Android we therefore use the UUID instead, which is a unique identifier for those devices. The post_auth script will work with that. Because originally only MAC addresses were accepted the documentation may still reference only MAC address, but it will also accept UUIDs.

One can easily change a PC's MAC (thank god, tinkering ftw) but on smartphones? Tho the new smartphones randomize their Wi-Fi MACs... so yes the UUID is actually worse.
The only solution to cure paranoia: a custom OpenVPN client.

The relevant lines are here:
Where variables are added: https://github.com/OpenVPN/openvpn/blob/d49df6bdde0592c9f795a2a260f6f04255b32303/src/openvpn/ssl.c#L2208
Definition of push_peer_info_details (it is not a config option, its an internal variable in code only): https://github.com/OpenVPN/openvpn/blob/6cf4fa5a4a686fa99ccdc8b1df48616853bc6be6/src/openvpn/init.c#L2865

The patch wouldn't be too hard for someone to maintain it's just a couple lines.
-
It doesn't matter much if it's all gone as soon as the connection is closed, but strictly speaking it's not necessary. Anyway due to the push-peer-info requirement, the burden is pushed onto clients to use a proper one

PS: https://airvpn.org/linux/  lists NetworkManager and the forum threads do have warnings, but no explanations about what critical problems there are, like the ones discussed above. Again room for improvement

Finally: F**ing solid. Seriously. I've never thought I'd dig so deep into OpenVPN and its configuration, but this the highest level of nit picking, that stuff above is all I can come up with. I must be a very special snowflake. Everything else about AirVPN is absolutely rock solid as far as my usage goes. OTOH it'd be interesting to see how many other VPN providers use push-peer-info without a real reason or what their "custom clients" do in the shadows.
Thanks for your service and thoughtful communication!

[OpenSourcerer 1435]

7 hours ago, Stalinium said:

After consideration it's indeed a not proper, but sane solution to just not use NM (OpenSourcerer's answer just highlights yet another issue). It's a shame it's practically default in all distros with such glaring issues.

NetworkManager in itself is a brilliant piece of software. It's its OpenVPN plugin that is half-baked and should not be used. Let's not drift into a discussion about why the world sucks when only a small part of it does.

[Staff 9971]

@Stalinium

Quote

After consideration it's indeed a not proper, but sane solution to just not use NM (OpenSourcerer's answer just highlights yet another issue). It's a shame it's practically default in all distros with such glaring issues.

Hello!

We recommend not to use network-manager-openvpn plugin, not NM; in itself, as you and OpenSourcerer have rightly noted. Hopefully the OpenVPN plugin bugs will be fixed soon. We have no voice on it.

Quote

Forums are great, but just like with anything, finding the right information when needed is a problem sometimes. It's not like I intentionally ignored it just never found. Oh and while at it, the thread's topic can also be improved, it's not just Debian: Ubuntu, Manjaro, most likely other Debian-derivaties. As I said I think a warning banner will suffice.

Of course, nobody implied that you intentionally pretended to ignore the suggestion.😋

The disclaimer was anyway added and integrated in the Linux instructions some years ago, so it's not only an isolated post. We were confident that in some months the most critical issues would have been fixed but according to your report they are not (and new ones have accumulated, apparently...), after several years, so we're not optimistic anymore. Since we release a variety of software for Linux that should make nm-ovpn irrelevant and inferior, we do not follow actively that plugin development.

Thank you for your feedback, suggestions noted!

Kind regards