Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support for using port 53 for Wireguard #1593

Closed
Astorsoft opened this issue Sep 30, 2019 · 6 comments · Fixed by #1594
Closed

Support for using port 53 for Wireguard #1593

Astorsoft opened this issue Sep 30, 2019 · 6 comments · Fixed by #1594

Comments

@Astorsoft
Copy link

Astorsoft commented Sep 30, 2019

Is your feature request related to a problem? Please describe.

As Wireguard is operating on UDP, it is quite common on corporate and some public networks to be impossible to reach the VPN server as most UDP ports are blocked. A common tactic is then to setup Wireguard to listen on port 53, usually used by DNS, as it is very rarely filtered. This is a similar approach as using TCP443 for OpenVPN. However, if you try to put 53 as the Wireguard port in config.cfg, the deployment breaks when it tries to start the Wireguard service (wg-quick@wg0) as the port is already used by Systemctl resolved/dnscrypt-proxy.

Describe the solution you'd like

Could the local dns resolver /dnscrypt proxy be listening on another IP? Such as an ip within the wireguard default subnet like 10.19.49.53? Or 172.16.10.53?

Describe alternatives you've considered

I've tried changing the dns resolver to listen on port 5353 but I could not find a way to edit Wireguard client profiles to change the DNS listening port.

I've tried setting up the dns on another IP as suggested in the solution as well but to no avail, however, I'm pretty sure the issue lies between keyboard and chair and not into the solution itself ;).

@davidemyers
Copy link
Contributor

As configured by Algo, systemd-resolved and dnscrypt-proxy already listen on private IP addresses, and neither listens on any public IP address. I believe the issue is that WireGuard insists on listening on all IP addresses, thus creating the conflict when you tell WireGuard to listen on port 53.

One suggestion is to use iptables to forward requests coming in on the public addresses from port 53 to wherever WireGuard is really listening. Algo would need a few changes to handle this special case.

@Astorsoft
Copy link
Author

Thanks @davidemyers, I'll try this solution on my setup and tell you how it went, having this edge case managed automatically would be awesome though :)

@davidemyers
Copy link
Contributor

I was able to get it to work with the following changes to the Algo source. There's some ugly hardcoding here and I'm ignoring IPv6 but it could be turned into a proper PR. I'd like to know if it works for you and gets you past the UDP blocking you've encountered.

If you download a copy of Algo using git clone you should be able to save the changes below to a file and apply them with git apply.

diff --git a/config.cfg b/config.cfg
index 5cb3eaa..9c56bcc 100644
--- a/config.cfg
+++ b/config.cfg
@@ -33,7 +33,7 @@ strongswan_network_ipv6: 'fd9d:bc11:4020::/48'
 
 # Deploy WireGuard
 wireguard_enabled: true
-wireguard_port: 51820
+wireguard_port: 53
 # If you're behind NAT or a firewall and you want to receive incoming connections long after network traffic has gone silent.
 # This option will keep the "connection" open in the eyes of NAT.
 # See: https://www.wireguard.com/quickstart/#nat-and-firewall-traversal-persistence
diff --git a/roles/common/templates/rules.v4.j2 b/roles/common/templates/rules.v4.j2
index 4d8f60b..b4f9801 100644
--- a/roles/common/templates/rules.v4.j2
+++ b/roles/common/templates/rules.v4.j2
@@ -1,5 +1,5 @@
 {% set subnets = ([strongswan_network] if ipsec_enabled else []) + ([wireguard_network_ipv4] if wireguard_enabled else []) %}
-{% set ports = (['500', '4500'] if ipsec_enabled else []) + ([wireguard_port] if wireguard_enabled else []) %}
+{% set ports = (['500', '4500'] if ipsec_enabled else []) + ([wireguard_port, '51820'] if wireguard_enabled else []) %}
 
 #### The mangle table
 # This table allows us to modify packet headers
@@ -29,6 +29,8 @@ COMMIT
 :PREROUTING ACCEPT [0:0]
 :POSTROUTING ACCEPT [0:0]
 
+-A PREROUTING --in-interface {{ ansible_default_ipv4['interface'] }} -p udp --dport 53 -j REDIRECT --to-port 51820
+
 # Allow traffic from the VPN network to the outside world, and replies
 -A POSTROUTING -s {{ subnets|join(',') }} -m policy --pol none --dir out -j MASQUERADE
 
diff --git a/roles/wireguard/templates/server.conf.j2 b/roles/wireguard/templates/server.conf.j2
index b7a8580..912a5a3 100644
--- a/roles/wireguard/templates/server.conf.j2
+++ b/roles/wireguard/templates/server.conf.j2
@@ -1,6 +1,6 @@
 [Interface]
 Address = {{ wireguard_server_ip }}
-ListenPort = {{ wireguard_port }}
+ListenPort = 51820
 PrivateKey = {{ lookup('file', wireguard_pki_path + '/private/' + IP_subject_alt_name) }}
 SaveConfig = false
 

@Astorsoft
Copy link
Author

Oh wow thanks for that, I will try it tomorrow evening and see how it goes :)

@Astorsoft
Copy link
Author

Astorsoft commented Oct 1, 2019

Ok so I actually took to time to test it tonight and it works on my Macbook and my Android using DigitalOcean in Amsterdam. This is awesome! I've not tinkered with the config.cfg but I don't see why changing the dns, adding profiles or enabling unmanaged security updates would break it anyway.

I'm not traveling at the moment so I don't have any use case for the UDP blocking right now, I'll try this part next time I get a chance but as long as they don't do DPI that should do the trick.

Thank you!

@davidemyers
Copy link
Contributor

I submitted a PR to add this feature.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants