-
-
Notifications
You must be signed in to change notification settings - Fork 2.3k
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
Comments
As configured by Algo, One suggestion is to use |
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 :) |
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 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
|
Oh wow thanks for that, I will try it tomorrow evening and see how it goes :) |
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! |
I submitted a PR to add this feature. |
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 ;).
The text was updated successfully, but these errors were encountered: