[Feature request] Support SOCKS proxy when using udp-over-tcp wireguard

[x0wllaar]

Feature Request

Operating system: Linux/Windows/macOS

App version: 2023.1

Issue description

I would like to see an ability to tunnel udp-over-tcp Wireguard traffic through a custom SOCKS5 proxy, that can be specified somewhere in the app interface, or, as it is an advanced feature, on the command line.

Rationale

This will make the VPN much more resilient to a large number of network filtering / censorship techniques. Currently, the Mullvad VPN servers are publicly known, and can be blocked by IP, or could be blocked by DPI by a motivated adversary, even if udp-over-tcp is used.

A large number of censorship circumvention tools and approaches exist (notably, SSH tunneling and Tor) that expose themselves to their clients as SOCKS5 proxies, as this protocol is widely supported by user applications. Thus, enabling this feature will lay the necessary groundwork for using Mullvad in restricted/censored networks.

Currently, this is supported using OpenVPN with a tuned config, but I would love to see this supported on Wireguard and in the app.

Possible Use Cases

I have seen reports of users in China using SSH tunnels to DigitalOcean droplets to bypass the GFW. I can't seem to find links to them now, but I will add them when I find them.

I've also been in situations where the only way to connect to the internet was via an SSH tunnel, and I used Mullvad's OpenVPN to tunnel my traffic over this tunnel.

Additionally, some users might benefit from VPN-over-Tor usage. This usage has not that many benefits, but it might be useful if someone wants to tunnel UDP over Tor for whatever reason.

Ease of implementation

Given the existence of udp-over-tcp, my (very, very quick and shallow) preliminary investigation shows that this functionality might be implemented using existing tools that are widely available by default on Linux and macOS and can be brought over to Windows.

udp-over-tcp does not natively support SOCKS proxying, but it can be tunneled over a SOCKS connection using netcat. For example:

On one terminal: ncat -l 55081 -e "/bin/nc -X 5 -x PROXYIP:PROXYPORT nmcheck.gnome.org 80" On another:

curl -v -H 'Host: nmcheck.gnome.org' http://127.0.0.1:55081/check_network_status.txt        
*   Trying 127.0.0.1:55081...
* Connected to 127.0.0.1 (127.0.0.1) port 55081 (#0)
> GET /check_network_status.txt HTTP/1.1
> Host: nmcheck.gnome.org
> User-Agent: curl/7.85.0
> Accept: */*
> 
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< server: nginx/1.23.2
< date: Wed, 08 Mar 2023 17:48:50 GMT
< content-type: text/plain
< content-length: 25
< vary: Accept-Encoding
< expires: Wed, 08 Mar 2023 17:48:49 GMT
< cache-control: no-cache
< content-type: text/plain
< set-cookie: 82e0a9831c6eef18e45051ceea83040a=660d83a64f64950904cb103c40dbbab7; path=/; HttpOnly
< 
NetworkManager is online
* Connection #0 to host 127.0.0.1 left intact

We can see that any TCP traffic could be easily forwarded over SOCKS5 using netcat (here, I am using both the nmap netcat and the default one)

The same approach could be used for udp-over-tcp, by first running ncat -l 9001 -e "/bin/nc -X 5 -x PROXYIP:PROXYPORT 1.2.3.4 9000", and then connecting udp2tcp on the client to 127.0.0.1:9001.

Alternatively, SOCKS5 support could be added directly to udp-over-tcp, as the necessary subset of the protocol is not that hard to implement.

[faern]

Thanks for the feature request. Yes, we are planning for better obfuscation and connection methods when using WireGuard. We are currently investigating replacing udp-over-tcp with some "fake TCP" implementation. Because they perform way better (it's not good for performance to tunnel things in a TCP connection). If we go ahead with this, our app will no longer emit valid TCP and it can't operate over some other channel that can forward TCP.

With that being said. We of course want to add other obfuscation methods to WireGuard to allow it to circumvent censorship in various ways. Thanks for some great input.

[x0wllaar]

Thank you! I would also add that I was on some networks that blocked all UDP traffic outright, while allowing essentially all TCP through (it was a hotel Wi-Fi network). I think that keeping at least some "real TCP" backup option is a must for these networks.

[d4f5409d]

I would also love a proxy layer on top of Mullvad. Maybe to support Tor Snowflake bridges that lets us connect to Mullvad.