Potential Wireguard misconfiguration question wrt route_allowed_ips

Installing and Using OpenWrt Network and Wireless Configuration
1

TLDR: some Wireguard client peers have option route_allowed_ips '1' set and some don't. Everything works as expected. Is this a misconfiguration?

Prompted by a comment from @psherman about the option route_allowed_ips '1'

I'm wondering if there's a misconfiguration somewhere in my setup, specifically related to all "client" peers needing option route_allowed_ips '1' or not. This is my first Wireguard setup directly on OpenWrt, so I don't quite understand all the knobs yet.

In this scenario there are 2 routers running OpenWrt 24.10.0: GW0 and GW1. LAN1 is connected over Wireguard to LAN0. In case of GW0 Wireguard is running on the router itself, and in case of GW1 it's running on WG1 that is a Raspberry Pi Zero 2W "hat". The LANs behind both routers are fully routable, along with the DNS resolution both ways. External "client" peers CL0...CLN connect to GW0 and can be reached from both LANs.

Here's a crude network diagram:

    	                       [WG1]
                                 |
 [LAN0]---[GW0]---[Internet]---[GW1]---[LAN1]
            |
            |---[Internet]---[CL0]
                           |
                           |-[...]
                           |
                           |-[CLN]

GW0, on 24.10.0

  • 10.0.1.1/24 LAN0
  • 10.0.3.1/32 Wireguard peer IP
  • Runs Wireguard “server” peer, plus listens to “clients” peers
  • Runs Ardguard Home with DNS from GW1 as one of the upstreams and rDNSs to resolve local and LAN1 hostnames
  • Doesn’t have explicit static routes
  • Has port open for WG
  • GW1 site-to-site peer has option route_allowed_ips '1'
  • Client peers don’t have option route_allowed_ips set

The question is about the GW0 side, but here's GW1 for completeness.

GW1, also on 24.10.0

  • 10.0.2.1/24 LAN1
  • Has explicit static routes 10.0.1.0/24 and 10.0.3.0/24 to WG1 10.0.2.30

WG1, on a Raspberry Pi Zero 2W with Debian Buster connected through a USB gadget to the router

  • 10.0.2.30
  • 10.0.3.2/24 Wireguard peer IP
  • Runs Wireguard “client” peer to GW0
  • Runs Ardguard Home with DNS from GW0 as one of the upstreams and rDNSs to resolve local and LAN0 hostnames
  • Has net.ipv4.ip_forward=1 and net.ipv4.conf.all.proxy_arp=1 set in /etc/sysctl.d/
  • No other rules like masquerading, etc.
abbreviated /etc/config/network from GW0 
config interface 'lan'
	option device 'br-lan.101' # there are several VLANs
	option proto 'static'
	option ipaddr '10.0.1.1'
	option netmask '255.255.255.0'
	option ip6assign '60'

config interface 'wgsmth'
	option proto 'wireguard'
	option private_key 'xxx'
	option listen_port '1234'
	list addresses '10.0.3.1/24'

config wireguard_wgsmth
	option description 'WG1 site-to-site'
	option public_key 'xxx'
	option persistent_keepalive '25'
	option route_allowed_ips '1'
	list allowed_ips '10.0.2.0/24'
	list allowed_ips '10.0.3.2/32'

config wireguard_wgsmth
	option description 'CL0 regular client'
	option public_key 'xxx'
	list allowed_ips '10.0.3.7/32'
abbreviated /etc/config/firewall from GW0 
config rule
	option name 'Allow Wireguard'
	list proto 'udp'
	option src 'wan'
	option dest_port '1234'
	option target 'ACCEPT'
example client peer config 
[Interface]
PrivateKey = xxx
Address = 10.0.3.7/24

[Peer]
PublicKey = xxx
Endpoint = public.dns:1234
AllowedIPs = 0.0.0.0/0
PersistentKeepalive = 25
DNS = 10.0.1.1

The relevant routes that are created automatically on GW0 look like this, so I'm speculating site-to-site peer having option route_allowed_ips '1' is enough.

10.0.2.0/24 dev wgminos proto static scope link 
10.0.3.0/24 dev wgminos proto kernel scope link src 10.0.3.1 
10.0.3.2 dev wgminos proto static scope link
2

Consider that a lot of WireGuard clients do not even have the option Route Allowed IPs but they do that by default
Some firmwares e.g. DDWRT have this option (not surprisingly as it is the person who implemented did have a good look at OpenWRT) but it is enabled by default and that is exactly as it should be, it should be enabled by default.

Many WireGuard users come to the forum asking for help only to discover that they forgot to enable Route Allowed IPs and thus it is not working.

After my rant on to your question.

Yes you should enable it as it does not hurt.

Why does it work in your case without enabling it, is because your WireGuard address has a /24 subnet, Linux automatically makes a route to route your subnet over the WG interface

1 Like
3

As you have used /24 as the subnet mask for the wireguard interface on GW0 this will create a route sending packets for that subnet to that interface. As the client peers use addresses from that subnet you don't need to create additional routes, either by using route_allowed_ips or doing it manually.

I disagree. It's a useful tool but I much rather have authority over what routing rules are added. It's also much simpler to resolve a situation where the issue is the box hasn't been ticked, rather than one where it has and it's caused issues with pre-existing rules.

Advice should in most situations should be to turn it on, but it should be an action carried out by the user.

1 Like
4

It certainly is a very useful tool but in 98 out of 100 cases it should be enabled (think all the WireGuard clients to VPN providers, and all the simple WireGuard server setups where people are instructed to use /32 addresses etc)

1 Like
5

I don't disagree it should be enabled, just over whether it should be a conscious action or not. I favour the former but appreciate that other views are available

2 Likes