Allow WireGuard to listen on port 53

[davidemyers]

Description

This change allows the special case of setting wireguard_port: 53 in config.cfg and is based on an approach suggested on the WireGuard mailing list.

Motivation and Context

Some networks block most outgoing UDP traffic, but port 53 might still be allowed for DNS.

Closes #1593.

How Has This Been Tested?

Deployed to DigitalOcean both with and without wireguard_port: 53. Also tested connecting using a DigitalOcean Floating IP, where traffic comes in on the main network interface but to a secondary address. In all cases the client was iOS 13.1.2.

Also tested on Lightsail with wireguard_port: 53.

More testing should be done. Please help test this, fellow Algo users.

This should also be reviewed for how it uses iptables.

Types of changes

• New feature (non-breaking change which adds functionality)

Checklist:

• I have read the CONTRIBUTING document.
• My code follows the code style of this project.
• All new and existing tests passed.

[TC1977]

Wonder if this would help solve #1586 and #1588.

[davidemyers]

I've found an issue that I don't believe is specific to this PR but should be noted as it is likely a showstopper for many.

Using port 53 with WireGuard does not appear to work at all over Verizon Wireless LTE (using an iPhone, anyway). I don't have a way to test other carrier networks.

[TC1977]

I'm gonna try to spin up a server later today to test this out on AT&T LTE network.

Wouldn't this also be a useful feature for IPsec users as well? One big appeal of OpenVPN is to select the outgoing port at will. You could set the outgoing port to whatever you want in config.cfg, set the open cloud/local firewall ports accordingly, and use iptables to redirect it to UDP/500 and 4500 on the Algo server. Might be outside the scope of this PR, though.

[davidemyers]

I don't believe there's a way of tell most IPsec clients to use alternate ports.

I'm curious to know if this works over AT&T.

[TC1977]

Ok, so here's what I did:
Created an Ubuntu 19.04 droplet on DO, IPv6 enabled
Used git clone and git checkout wg53 to switch to this PR
Ran through steps 3-5 of the install instructions
Changed wireguard_port in config.cfg to 53
Ran ./algo and chose local install, adblocking, save CA key, no other options.
Created a DO firewall to allow UDP/53 in and TCP/22 only.
Connected using the laptop.conf on MBP on LAN to server, web browsing and adblocking work.
Connected using the phone.png on iPhone on LAN to server, web browsing and adblocking work.
Switched to LTE on AT&T network - connection drops instantly, app log says "Handshake did not complete after 5 seconds, retrying"
Switched back to Wi-Fi - web browsing and adblocking work again.

[davidemyers]

Thanks for the testing, that's the same behavior I found. It also fails on an iPad when using the iPhone's Personal Hotspot (hotspot traffic is sent "in the clear", not over the phone's WireGuard tunnel, which is nice because it avoids double tunneling and the resulting MTU issues).

So this PR is a lot less useful than I had hoped it would be.

[TC1977]

It's not like I have a better idea, but can we have more descriptive names than wireguard_port_actual and wireguard_port_avoid? I would have no idea what those mean.

[davidemyers]

I'm open to suggestions. Where they come from is WireGuard must "avoid" listening on port 53 and instead "actually" listen somewhere else.

Since those variables aren't in config.cfg and won't be seen by most users I'm not sure the naming is really that important.

[TC1977]

So if someone sets wireguard_port in config.cfg to port 53 (or whatever you've set wireguard_port_avoid to), iptables will silently redirect traffic to the standard port of 51820 instead. And Wireguard won't actually be listening on port 53, but on port 51820. Is that correct?

It might be good to document this behavior in config.cfg, as I don't think anyone would expect it. I'd also suggest adding wireguard_port_avoid as a potential variable in the Ansible docs. (I'm still trying to think of a more intuitive name.)

[davidemyers]

So if someone sets wireguard_port in config.cfg to port 53 (or whatever you've set wireguard_port_avoid to), iptables will silently redirect traffic to the standard port of 51820 instead. And Wireguard won't actually be listening on port 53, but on port 51820. Is that correct?

Yes, that's the recommended approach according to the mailing list message I linked to above.

It might be good to document this behavior in config.cfg, as I don't think anyone would expect it.

My intention was to make this transparent to the user so that setting port 53 in config.cfg "just works". We now know that mobile data providers have other ideas, but I don't see why a user needs to know that iptables trickery is going on.

[TC1977]

It does make sense to make this transparent to the user, but I see two issues:

• Algo obviously serves a lot of the "prosumer" or outright pros who have an idea what they want to accomplish, but may not have the time/knowledge to go hunting around for iptables rules and WireGuard mailing list suggestions. Therefore it won't prevent future issues opened by people who want to have WireGuard listen on some other reserved port.
• The more places you put these options, the harder it will be to maintain these features as time goes on and the underlying software gets upgraded.

I'd suggest renaming it wireguard_port_avoid to wireguard_port_masquerade (sounds iptables-ish 😄 ) and putting it in config.cfg with appropriate documentation. There's already precedent for putting iptables rules mods with block_smb and BetweenClients_DROP in config.cfg.

[davidemyers]

The term "masquerade" has a particular meaning in iptables and I think using it here could be misleading.

The problem with promoting the variable to config.cfg is that it implies this feature is more generally useful than it really is. For this approach to work, nothing must be listening to the conflicting port on any IP address assigned to the primary network interface, meaning it won't work for most port conflicts a user is likely to encounter.

In the case of port 53, on an AlgoVPN systemd-resolved (by default) and dnscrypt-proxy (as configured by Jack) listen on private addresses, not on the primary network interface. However I can't think of another port likely to be used on a server where only private addresses would be used, and that a user would also want to use for WireGuard.

[TC1977]

In the case of port 53, on an AlgoVPN systemd-resolved (by default) and dnscrypt-proxy (as configured by Jack) listen on private addresses, not on the primary network interface. However I can't think of another port likely to be used on a server where only private addresses would be used, and that a user would also want to use for WireGuard.

Yeah, neither could I. Well, I have no further objections then.

[msuiche]

I just want to say that his is a beautiful pull request.