Tunneling tunnels - masquerading wireguard
... ooga booga tunnelception
Writeup start: 2024-12-29
Writeup finish: 2025-01-09
Update: 2025-03-28
Picky firewalls
Some weeks ago I have found myself in a dire situation.
Behind a picky firewall.
I could not connect to my wireguard VPN! Now apparently, there is some motivation for some firewalls to disallow any internet-connections to ports other than, like 80 (http) and 443 (https).
Their reasons? I am not sure. But I am not here to reason about their motivaiton. Much rather, I'm interested in how to restore full internet access!
Putting on a mask
Now, for the internet to be accessible at all, aforementioned HTTP(S)-ports remain open. This isn't likely to change anytime soon. Thus, if it could be possible for our wireguard traffic to look like some incarnation of HTTP, while connecting to a remote 443, we'd be good.
Here go the technical details:
makes it possible to tunnel any traffic through websocket, which is a HTTP/1.1-based protocol that can be used for transmitting arbitrary data. Since it is used by video-conferencing software, it is a widely accepted protocol that (should) survive(s) deep-packed-inspection.
You'll need one instance on your wireguard server and on your client, the latter being behind the picky firewall. To get a working copy of that software, you can have a look at the release page of its github repository, as many platforms are covered there.
Except one!
Yes, OpenBSD is not covered! Sike! But wait! I've got you covered. Anyone here on OpenBSD and feeling adventurous can try the port that I've submitted to the ports mailing list:
openbsd-ports mailing list - NEW: net/wstunnel
it is still waiting for another OK to be imported though. It builds fine however. Quite an interesting thing to see how OpenBSD folk manage to package rust with makefiles. They don't even call cargo! (If I understand correctly.) They actually pull each crate specified in Cargo.lock into a sourcedir and build from that; The upside here is that these locked dependencies can then easily be patched locally.
EDIT: the port was merged, it will be included in OpenBSD 7.7 :)
wstunnel on the server
Given that you have a wstunnel binary on your server, you can make it listen for websocket connections like this:
# wstunnel server --restrict-to 127.0.0.1:51820 wss://0.0.0.0:443
Or equivalently, if you use the OpenBSD port:
# rcctl set wstunnel flags server --restrict-to 127.0.0.1:51820 wss://0.0.0.0:443 # rcctl start wstunnel # rcctl enable wstunnel
This will now make it listen on your server's HTTPS port. Depending on your setup, this is not desirable - for example, what if you have some webserver running on that port already? We will come back to that later. For now, just assume that we will connect to your server over port 443. The `--restrict-to` argument tells that any wstunnel client may only connect to port 51820 of localhost; This is the standard wireguard port. I also assume that you have wireguard setup already - I am not covering this. If you need any hints, feel free to check out
~solene: Full WireGuard setup with OpenBSD
as an example. There are many others for Linux, I just found this one to be the best for OpenBSD. In fact, you don't even need wg-quick to keep your sanity there.
wstunnel on the client
Now, to have some comfortable automation on your client, a few more steps are needed. As this calls for scripting and I like to script in fish, because it feels the most similar to "general programming languages", I'll provide examples in the fish scripting language.
Lets start with the basics and set our endpoint that we will connect to. This may as well be some IP address, it only needs to point to our server running the listening instance of wstunnel:
#!/usr/bin/env fish set -l endpoint wss://gateway.example.org
I personally only connect through wstunnel if I have to, as wrapping tunnels in tunnels adds unnecessary overhead that I'd like to not have when not necessary. That is why I keep any wireguard over websocket tunnels as seperate configurations in `/etc/wireguard` - actually, the only thing that needs changing there is the `Endpoint = ` entry which from now on needs to be changed to `Endpoint = 127.0.0.1:51820`, compared to configuration that you'd use for "usual" wireguard connections.
Also, I'd like my script to toggle the connection. For this, we first check if our wireguard-over-websocket tunnel is already running:
if ip addr show wswg0 2>&1 > /dev/null
wg-quick down wswg0
eval "sudo ip route del $(cat $XDG_RUNTIME_DIR/wswg-quick.route)"
systemctl --user stop wstunnel
exit
endThis actually spoilers a lot what will come in the following. Line by line:
- we delete our tunnel*tunnel interface
- we delete some route that is defined in some temporary file
- we stop wstunnel (which will be run over systemd in the background)
The problem for our websocket tunnel is that it will connect to our server over the "regular internet". But usually, wireguard clients are configured by `AllowedIPs = 0.0.0.0/0` to route all their traffic through our tunnel. Of course, we cannot route our websocket tunnel through our wireguard tunnel that is supposed to be tunneled through websocket. For this, we need to manually set our routes. I have come up with some commands to ease this process:
set -l remote "$(getent ahosts gateway.example.org | head -1 | cut -d' ' -f1)"; or exit set -l gateway "$(getent ahosts _gateway | head -1 | cut -d' ' -f1)"; or exit set -l device "$(ip route get $remote | grep -Po "(?<=dev )[a-z0-9]+")"; or exit
Note that this will probably not work for IPv6-only networks. It hasn't failed me yet, though.
We now need to run the wireguard client instance. I like to run it as a transient systemd service under my current user, so I do:
systemd-run --user --unit wstunnel --description "wstunnel to $endpoint" -- \
wstunnel client \
-L 'udp://51820:127.0.0.1:51820?timeout_sec=0' \
$endpointAnd finally to apply and save (for it to be easily removed again) the route for our websocket tunnel, to then up our wireguard tunnel:
echo "$remote dev $device via $gateway" > $XDG_RUNTIME_DIR/wswg-quick.route sudo ip route add $remote dev $device via $gateway wg-quick up wswg0
And that's it!
Running that script a second time should cleanly tear down your two tunnels, including the custom route.
wstunnel behind a nginx reverse proxy
As previously mentioned, it might not be possible to make the server instance listen on 443, as you might have some webserver already running on that port. However, we need to connect over 443 since otherwise, we might not be able to pass through picky firewalls. Do not worry though! Reverse-proxying wstunnel over nginx is totally doable, and you can even enable HTTP basic auth for some additional foolproofing, as this is supported in the wstunnel client implementation:
map $http_upgrade $connection_upgrade {
default upgrade;
'' close;
}
server {
listen 443 ssl;
listen [::]:443 ssl;
server_name gateway.example.org;
# add ssl-certs, etc.
gzip off;
location / {
proxy_pass http://127.0.0.1:4443;
auth_basic "gateway.example.org"
auth_basic_user_file /path/to/.htpasswd;
proxy_buffering off;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection $connection_upgrade;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
}This snippet should get you started. In case you add basic auth, you need to provide the `--http-upgrade-credentials` option to your client. Otherwise, you can just remove both lines from the nginx configuration. The server instance of wstunnel also needs adjusting - since we now proxy and terminate SSL through nginx, listening on `ws://127.0.0.1:4443` is enough. And while we are at it, adding `--tls-verify-certificate` to your client's options makes sure that nobody is impostering your server. Finally, the last added header `X-Forwarded-For` will add the client's IP address to the logs of your server's wstunnel, because wstunnel actually looks for that header. Nice!
Source