I have successfully managed to set up Wireguard so that a peer (a mobile in this case) can connect to a router running OpenWRT. I can see on the mobile that all internet traffic is being routed via the VPN. I can also ping the router on both its LAN IP and WG IP, and name resolution is working for local servers. I can also ping the mobile on its WG IP from the router.
However I cannot access any other hosts on the LAN. I suspect this is a firewall issue, but it could be a routing one. I have "Route Allowed IPs" set (although I'm not too clear on what it does or why it's an option). My ip addresses are in the 10.10.0.0/16 range, and I use that scheme across my LAN and WG interfaces.
I have seen conflicting advice on how to set up the firewall:
- add the WG interface to the lan zone (via https://openwrt.org/docs/guide-user/services/vpn/wireguard/server)
- create a new wg zone and set up forwards from wg to lan and wan, and from lan to wg (via posts on this forum)
Neither options seem to fix the issue. Checking
iptables seems to indicate nothing is being rejected (ie the counts for reject rules don't change).
What's the best way to diagnose this issue?
Please run the following commands (copy-paste the whole block) and paste the output here, using the "Preformatted text
</> " button:
Remember to redact passwords, MAC addresses and any public IP addresses you may have
ubus call system board; \
uci export network; uci export dhcp; uci export firewall; \
head -n -0 /etc/firewall.user; \
ip -4 addr ; ip -4 ro li tab all ; ip -4 ru
It's quite sizable so I've pasted it here:
You can't use 10.10.0.0/16 for both the LAN and Wireguard interfaces. You need to change one of them.
If your intention is to allow trusted devices to connect to your network remotely then add the vpn interface to the LAN firewall zone.
10.10.0.0/16 was actually a later try.
I've used 10.10.20.1/32 and 10.10.20.2/32 for the openwrt and mobile peers respectively, and still no go. Are you saying they can't overlap at all?
While we're on the subject, why do so many of the WG examples (including the openwrt one) give a wide address space to the WG interface on the "server"? What purpose does that serve?
Yes, it needs to be addresses in a completely different subnet.
I see! Changing the respective tunnel IPs to 10.6.0.1 and 2 respectively does allow me to ping the LAN... but now I've lost DNS and lookups don't work. Strangely it's only for LAN hosts - the internet works fine. Conversely LAN names were being resolved in the broken set up above.
I've moved the vpn interface into the LAN zone if that means anything.
Post again the same diagnostics to see how it is now.
Here's the latest config:
I'm using dnscrypt if that's important, although I am able to reach the router's IP (which I think is used by the LAN hosts to resolve names)
You have option
localservice '1' and the wg address is /32, change it to /24 so it will cover the client address too.
This did the trick and everything is working as it should.
WG's approach to IP assignment seems to trip up a few people and I must admit I don't quite understand the fix, or why the router's WG interface needs more than one IP address, especially since I could ping the DNS server anyway.
Any insight would be appreciated.
EDIT: I think I understand - DNS will only be served to addresses covered by "local" IP addresses (
localservice), and adding /24 puts the client addresses "in scope".
However doesn't this mean that the router's WG interface now shares an IP address with a peer?
In my WG's interface settings I now have:
IP Addresses: 10.6.0.1/24
Isn't that setting all addresses in 10.6.0.x to that interface? Isn't that specifically why DNS now works?
It is setting address 10.6.0.1 with mask 255.255.255.0 to the interface, which means that 10.6.0.1-254 belong to the same network.
OK. I think I understand now. I was conflating what the CIDR notation meant in the interface address vs the allowed IP field (which I presume is a range).
Thanks for all the patience and help.
This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.