I have been using a Wireguard "server" on a linux box in my network for some time. This has allowed me to access all my internal resources and use my local DNS resolver for internet browsing. I simply forwarded the wireguard port on the router and have had no issues with this setup.
Now that I am using openwrt I planned on migrating my Wireguard to the openwrt router. I have spent days trying to get it to work to no avail. I assigned the wireguard interface to lan. The closest "success" I had was setting up a port forward to the local router IP address, but then I can only get a handshake and ping the router but nothing else in lan.
I assume this is not the correct approach and have setup a firewall rule to allow access from wan 51820 but that does not even allow a successful handshake.
Here are my current config files setup the way I believe they are supposed to be I also left in the port forward to my linux box that does work when enabled.
Firewall:
config redirect
option target 'DNAT'
option name 'Wireguard'
list proto 'udp'
option src 'wan'
option src_dport '51820'
option dest 'lan'
option dest_ip '192.168.1.12'
option dest_port '51820'
option enabled '0'
config zone
option name 'lan'
option input 'ACCEPT'
option output 'ACCEPT'
option forward 'ACCEPT'
list network 'lan'
list network 'Wireguard'
config rule
option name 'Wireguard'
option family 'ipv4'
list proto 'udp'
option target 'ACCEPT'
option dest_port '51820'
option src 'wan'
option src_port '51820'
option dest 'lan'
Network
config interface 'Wireguard'
option proto 'wireguard'
option private_key '<private>'
option listen_port '51820'
option delegate '0'
list addresses '10.6.0.1/24'
config wireguard_Wireguard
option description 'T3Kphone'
option public_key '<private>'
option preshared_key '<private>'
list allowed_ips '10.6.0.2/32'
option route_allowed_ips '1'
For a start, delete the two last lines in the Wireguard firewall rule and restart the firewall service.
config rule
option name 'Wireguard'
option family 'ipv4'
list proto 'udp'
option target 'ACCEPT'
option dest_port '51820'
option src 'wan'
If everything else is fine, you should get at least successful handshake without any port forwarding.
The rest could be firewall or routing issues.
Does the firewall of the LAN devices accept connections from 10.6.0.0/24?
After successful wireguard connection, temporary disable the firewall of 10.6.0.2 and start traceroute (if ping fails) from some LAN device (like 192.168.1.12)
I just removed the lines and you are correct I can now get a handshake! Thank you. I will do the additional steps you suggest when I get back home and have local access to my lan. Thank you for the step in the right direction!
Alright so I did as you suggested and disabled the firewall on 10.6.0.2 and did a traceroute from 192.168.1.12 to 10.6.0.2. It is pretty straight forward.
Tracing route to 10.6.0.2 over a maximum of 30 hops
1 <1 ms <1 ms <1 ms rout.int [192.168.1.1]
2 302 ms 301 ms 297 ms 10.6.0.2
to confirm it does not work the other way I tracert'ed from the vpned device to 192.168.1.12. It hops to 10.6.0.1 and times out after that.
Is appears the lan device can reach the vpned device but the vpned device cannot reach the lan devices. I presume this is a restriction in openwrt's firewall but I have seen nowhere in tutorials or other trouble shooting scenarios where they open any additional pathways presuming they assigned the wireguard interface to lan. I can't even make a rule to allow traffic from wirguard to lan because Openwrt treats them as one unit in Luci.
Check the firewall of the lan host. If it is a windows device, they block incoming packets from other networks by default. The firewall on OpenWrt is configured properly with both lan and Wireguard under lan zone.
Well shoot you are correct. Why do I need to add an additional rule when connecting to openwrt but not when I connect to my linuxbox through a port forward? Does this mean I need to configure the firewall of each windows and linux device to allow the network? Is there anyway I an configure the vpn connection itself to avoid this?
I was able to manually add a firewall rule to all my windows machines to get access to them even though this seems like a not ideal work-around. However, most importantly, I can not figure out how to open it up on the linux box. I can't seem to even find what firewall would be installed. It is an ubuntu server and when I check the status of ufw, it says it is disabled.
Ideally I feel like this should all be avoided with some type of proper routing but I am out of my league. Is this really what people do when they want access to their lan over wireguard via the router? The port-forward to a linux box in the lan method I was previously doing seemed was more straight forward.
Usually linux doesn't come with firewall enabled, or if it does, it doesn't have such a blocking rule to deny other networks.
You could NAT everything coming from the wireguard interface, but this would add a needless load on the cpu of the router.
You can check the firewall on the ubuntu with iptables-save -c
This is not a disabled firewall. Although the default policies are to accept all traffic I am not sure what is going on with the docker chains.
Disable it and try again:
ip address show; ip route show table all; ip rule show;
>
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: enp0s3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether 08:00:27:45:83:be brd ff:ff:ff:ff:ff:ff
inet 192.168.1.12/24 brd 192.168.1.255 scope global dynamic noprefixroute enp0s3
valid_lft 40581sec preferred_lft 40581sec
inet6 fe80::a00:27ff:fe45:83be/64 scope link
valid_lft forever preferred_lft forever
3: wg0: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420 qdisc noqueue state UNKNOWN group default qlen 1000
link/none
inet 10.6.0.1/24 scope global wg0
valid_lft forever preferred_lft forever
4: docker0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
link/ether 02:42:f0:86:59:7d brd ff:ff:ff:ff:ff:ff
inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0
valid_lft forever preferred_lft forever
inet 169.254.16.25/16 brd 169.254.255.255 scope global noprefixroute docker0
valid_lft forever preferred_lft forever
inet6 fe80::3a47:8f38:79b8:9d9c/64 scope link
valid_lft forever preferred_lft forever
6: vethd67ff88@if5: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master docker0 state UP group default
link/ether ce:03:b7:41:3b:01 brd ff:ff:ff:ff:ff:ff link-netnsid 0
inet 169.254.24.217/16 brd 169.254.255.255 scope global noprefixroute vethd67ff88
valid_lft forever preferred_lft forever
inet6 fe80::b325:ae30:26da:9b52/64 scope link
valid_lft forever preferred_lft forever
inet6 fe80::cc03:b7ff:fe41:3b01/64 scope link
valid_lft forever preferred_lft forever
default via 192.168.1.1 dev enp0s3 src 192.168.1.12 metric 202
10.6.0.0/24 dev wg0 proto kernel scope link src 10.6.0.1
169.254.0.0/16 dev docker0 scope link src 169.254.16.25 metric 204
169.254.0.0/16 dev vethd67ff88 scope link src 169.254.24.217 metric 206
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1
192.168.1.0/24 dev enp0s3 proto dhcp scope link src 192.168.1.12 metric 202
broadcast 10.6.0.0 dev wg0 table local proto kernel scope link src 10.6.0.1
local 10.6.0.1 dev wg0 table local proto kernel scope host src 10.6.0.1
broadcast 10.6.0.255 dev wg0 table local proto kernel scope link src 10.6.0.1
broadcast 127.0.0.0 dev lo table local proto kernel scope link src 127.0.0.1
local 127.0.0.0/8 dev lo table local proto kernel scope host src 127.0.0.1
local 127.0.0.1 dev lo table local proto kernel scope host src 127.0.0.1
broadcast 127.255.255.255 dev lo table local proto kernel scope link src 127.0.0.1
broadcast 169.254.0.0 dev docker0 table local proto kernel scope link src 169.254.16.25
broadcast 169.254.0.0 dev vethd67ff88 table local proto kernel scope link src 169.254.24.217
local 169.254.16.25 dev docker0 table local proto kernel scope host src 169.254.16.25
local 169.254.24.217 dev vethd67ff88 table local proto kernel scope host src 169.254.24.217
broadcast 169.254.255.255 dev docker0 table local proto kernel scope link src 169.254.16.25
broadcast 169.254.255.255 dev vethd67ff88 table local proto kernel scope link src 169.254.24.217
broadcast 172.17.0.0 dev docker0 table local proto kernel scope link src 172.17.0.1
local 172.17.0.1 dev docker0 table local proto kernel scope host src 172.17.0.1
broadcast 172.17.255.255 dev docker0 table local proto kernel scope link src 172.17.0.1
broadcast 192.168.1.0 dev enp0s3 table local proto kernel scope link src 192.168.1.12
local 192.168.1.12 dev enp0s3 table local proto kernel scope host src 192.168.1.12
broadcast 192.168.1.255 dev enp0s3 table local proto kernel scope link src 192.168.1.12
::1 dev lo proto kernel metric 256 pref medium
fe80::/64 dev enp0s3 proto kernel metric 256 pref medium
fe80::/64 dev vethd67ff88 proto kernel metric 256 pref medium
fe80::/64 dev docker0 proto kernel metric 256 pref medium
local ::1 dev lo table local proto kernel metric 0 pref medium
local fe80::a00:27ff:fe45:83be dev enp0s3 table local proto kernel metric 0 pref medium
local fe80::3a47:8f38:79b8:9d9c dev docker0 table local proto kernel metric 0 pref medium
local fe80::b325:ae30:26da:9b52 dev vethd67ff88 table local proto kernel metric 0 pref medium
local fe80::cc03:b7ff:fe41:3b01 dev vethd67ff88 table local proto kernel metric 0 pref medium
ff00::/8 dev enp0s3 table local metric 256 pref medium
ff00::/8 dev wg0 table local metric 256 pref medium
ff00::/8 dev vethd67ff88 table local metric 256 pref medium
ff00::/8 dev docker0 table local metric 256 pref medium
0: from all lookup local
32766: from all lookup main
32767: from all lookup default
sudo nft list ruleset
Command not found
I tried pinging the server with the vpn client while
sudo tcpdump -evni any icmp
was running
10:06:23.285685 In dc:a6:32:4d:74:5c ethertype IPv4 (0x0800), length 100: (tos 0x0, ttl 63, id 59591, offset 0, flags [DF], proto ICMP (1), length 84)
10.6.0.2 > 192.168.1.12: ICMP echo request, id 90, seq 5, length 64
That solved the problem! I feared removing this server as it was my only way of still getting access to my lan while troubleshooting this issue. I still wish I did not have to manually set a firewall rule on the windows machines (as I did not have to before) but I am calling this good enough! Thanks!
If you are interested why you didn’t have to modify the firewalls of the windows machines before, it’s because of that rule in the firewall of the Linux server.
[70621:6962130] -A POSTROUTING -o enp0s3 -j MASQUERADE
It hides all the traffic that leaves the LAN interface behind 192.168.1.12 and network 10.6.0.0/24 remains hidden. As @trendy has said, you could do the same on the OpenWrt router, but that would increase the CPU load. The manual modification of the firewalls is small inconvenience, compared to the better performance.