WireGuard custom / incompatible implementations

[Opayq 1]

The WireGuard privacy issue because of the non-dynamic IP addresses may not be much of a problem when connecting to WireGuard from a router to provide LAN clients with VPN access. See the answer on: Is WireGuard fixed IP address obtainable by LAN clients if VPN is running on the router? WebRTC/STUN risk? LAN clients should be unaware of the VPN and thus won't be able to expose the static VPN IP address.

However the fact that this is a statically assigned IP address still remains, which isn't ideal. So I hope AirVPN will implement a solution similar to NordLynx or ProtonVPN once WireGuard is taken out of beta.
 

[OpenSourcerer 1360]

40 minutes ago, Opayq said:

However the fact that this is a statically assigned IP address still remains, which isn't ideal. So I hope AirVPN will implement a solution similar to NordLynx or ProtonVPN once WireGuard is taken out of beta.

This likely won't happen because one of the goals was compatibility with standard Wireguard tools. The ones from Nord, Express and Proton are not standard.
*Well, I stand corrected, Lightway is not a Wireguard implementation.

[Opayq 1]

2 hours ago, OpenSourcerer said:

This likely won't happen because one of the goals was compatibility with standard Wireguard tools. The ones from Nord, Express and Proton are not standard.
*Well, I stand corrected, Lightway is not a Wireguard implementation.

Are you sure the other providers are incompatible with standard Wireguard tools? Looks to me as if NordLynx could be setup on OpenWRT with standard tools: https://forum.openwrt.org/t/instruction-config-nordvpn-wireguard-nordlynx-on-openwrt/89976

If they managed to solve this privacy issue without breaking compatibility with standard tools then I see no reason why AirVPN can't do the same.

[Daniel15 14]

2 hours ago, OpenSourcerer said:

This likely won't happen because one of the goals was compatibility with standard Wireguard tools.

As far as I can tell, this behaviour could be implemented with server-side-only changes, allowing standard WireGuard tools to still be used on the client side. For the use case of AirVPN/Nord/whatever where clients don't need to be able to communicate with each other, each client could have the same generic IP address on the client-side (looks like NordVPN always uses 10.5.0.2 for example), and the server-side would do some NAT-like translation to have a unique server-side RFC1918 IP based on the public key of the client. For example it could use a new IP every time a connection is made, or periodically rotate it (although that may cause issues with long-running connections).
I suspect the providers like NordVPN have done something like this and run a modified version of the WireGuard kernel module on their servers, or maybe even a custom userland version (eg a fork of wireguard-go), although that would reduce performance a bit.

[OpenSourcerer 1360]

2 hours ago, Opayq said:

Looks to me as if NordLynx could be setup on OpenWRT with standard tools

Think again: I explicitly need Nord's non-standard client to pull info a standard Wireguard needs, because Nord does not give this info away freely. And it's obvious why. They can't change how the Wireguard protocol works, if at all; if they want to make good on Wireguard's promise of better throughput, they must use the standard in-tree modules. If they wanted to rock their own version, they would need to ship their own kernel modules via dkms (this will raise eyebrows) or they'd need to implement it fully in userspace (this will raise hair instead; how is it better than OpenVPN, then?).
Yes, even Proton's Wireguard will work, after more or less tinkering, I'm very sure; because at the heart of it it's still the standard wireguard kernel module doing most of the clientside work. But you don't want to make it too easy for users. After all, you invested money and time into custom clients, and if people see that it's easier to connect with the easily installable wireguard-tools, what's the point of the custom client? All they can do is to compel you to run around and find funny little workarounds or make you give up and skinny dip into their analytics pool. Seems like Nord is very successful with the latter approach, seeing as you even need the client for finding these funny little workarounds… good for them.

AirVPN is much closer to the standard because you can generate a config, rename it and use it with wg-quick. You never needed a client for AirVPN to connect to AirVPN, why should that change with Wireguard?

I'd like to stop the discussion about other providers' implementations here, in a public announcement forum, where it's kinda off-topic. Should you have the desire to discuss this further, I invite you to open a thread in the Other VPN competitors forum; after all, it's there for exactly these kinds of discussions. Thank you for your understanding.

[Daniel15 14]

10 hours ago, OpenSourcerer said:

: I explicitly need Nord's non-standard client

 Well, kind of... I agree that they don't make the config easily accessible, but if you get the correct public and private keys (for example, from their command-line client), you can connect with any standard Wireguard client. That's what the page @Opayq linked to is saying. They use the NordVPN client only to get the config, but afterwards you can just use the same config with vanilla Wireguard on OpenWRT. The fact that you need their app for the initial config really isn't too different to the config generator on AirVPN's site...

Like I mentioned earlier, I strongly suspect they're just using NAT on the server side, using the public key as the key in the NAT table. No custom Wireguard client needed, just a custom server. The same thing would be doable with any provider if they put in some work to implement it

[Staff 9763]

Hello!

We have moved the discussion here because it was too off-topic in the beta testing thread and it polluted it. That thread is reserved to WireGuard testing in AirVPN and is aimed at finding bugs, malfunctions and so on, if any.

Kind regards
 

[Opayq 1]

I'm a bit surprised you find this discussion polluting the thread that's about beta-testing WireGuard provided by AirVPN. The current beta offering isn't ideal for privacy, which AirVPN confirms. I'm not interested in discussing incompatible WireGuard implementations. The way I understand it, and what @Daniel15 is confirming, is that AirVPN could fix the privacy issue while maintaining compatibility with standard WireGuard tools. Seems like this is valuable feedback and a valid request during a beta period. Manually regenerating the config from the AirVPN Client area and re-applying this manually in my router config just isn't a viable option for me.

[Whocares? 1]

On 1/28/2022 at 9:52 PM, Daniel15 said:

As far as I can tell, this behaviour could be implemented with server-side-only changes, allowing standard WireGuard tools to still be used on the client side. For the use case of AirVPN/Nord/whatever where clients don't need to be able to communicate with each other, each client could have the same generic IP address on the client-side (looks like NordVPN always uses 10.5.0.2 for example), and the server-side would do some NAT-like translation to have a unique server-side RFC1918 IP based on the public key of the client. For example it could use a new IP every time a connection is made, or periodically rotate it (although that may cause issues with long-running connections).
I suspect the providers like NordVPN have done something like this and run a modified version of the WireGuard kernel module on their servers, or maybe even a custom userland version (eg a fork of wireguard-go), although that would reduce performance a bit.

@Staff

Please don't do it! It's terrible having the same IP address from each connection slot, for it makes failover and load balancing through multiple connections to multiple servers from the same router or computer very hard if not impossible. All the virtual NIC get the same IP address, very bad. Leave atrocious solutions to subject like nord and its ilk and let wireguard run without customized, not peer reviewed kernel module changes that could turn out into being more dangerous than the evil they try to patch. Nord and other have already suffered data leaks for their incompetent security policy, they do not check for server IPMI, how can you trust a wireguard kernel code change form their side?!?

 

Edited ... by Whocares?