Wireguard road warriors as subnet in a LAN

Installing and Using OpenWrt Network and Wireless Configuration
1

Hello,

I've successfully set up wireguard on my Raspberry Pi OpenWrt installation, and managed to connect to it from some Android devices, being able to access some services in my LAN.

Since for the time being the Pi is just a normal host in my LAN, this required using a set of IP addresses foreign to my LAN subnet, the latter being 192.168.17.0/24. For reasons I'll not go into here I want the road warriors use IP addresses from a subnet within my LANs subnet, i.e. 192.168.17.192/28. The problem here is the routing from the LAN hosts to the Pi, for it to forward traffic to the road warrior(s). I do not want to set explicit routes on all the hosts for obvious practical reasons.

I can see three possible approaches, but since I have very limited experience with advanced networking setups, I'm not sure if they are up to the task, nor do I know respective advantages and drawbacks. So forgive me if I'm talking nonsense. Maybe someone can enlighten me, or point out alternatives?

a.) Setting up a bridge interface that includes the Pi's LAN and wireguard interfaces. I would think, this makes the road warriors receive ARP requests. I do not know though if the bridge would modify the road warrior's ARP replies to contain the Pi's interface MAC. This would be required so that LAN hosts know to send packets to the Pi's LAN interface.

b.) Setting up the Pi to act as an ARP proxy for the road warriors. The Pi would know to answer ARP queries directed to IP addresses from the road warrior subnet.

c.) Setting up relayd on the Pi, to make the road warriors visible on the LAN. I'm not sure though if that would make them answer ARP requests in a meaningful way.

For the long term, I plan to upgrade the Pi to become my upstream router (i.e. the ISP interface). In that situation the question is moot, as for the hosts routing requirements the gateway routing is sufficient to reach the road warriors. However I welcome the opportunity to learn about these advanced topics.

Cheers Peter

2

I found https://emanuelduss.ch/2018/09/wireguard-vpn-road-warrior-setup/ very helpful in understanding how WireGuard "works". Key concepts is that the WireGuard link is routed and there is no native L2 bridging and that "allowed IPs" is, at least for me, not instantly intuitive.

3

It is very clear to me that in the standard setup as Duss describes it Wireguard is routed. That's why I stressed at the beginning that I have successfully set it up using "foreign" IP adresses (that includes the "Allowed IPs" setting, of course). It is exactly my question how to make the routing "implicit" in the best way. I'm fairly sure that if I get it configured, option (b) should work, but I'm not so sure about (a) or (c). Anyway, if they do work, there'd be advantages or drawbacks which I'd like to learn about.

4

Personally, I consider relayd (and proxy ARP) quite a hack and it’s IPv4 only.

A “standard” WireGuard “road-warrior” config should cover a remote client’s access to the subnet. Routing if off-link is your choice as to split or unified into the tunnel.

1 Like
5

For a) you would need to setup a layer2 tunnel such as gretap or vxlan on the wireguard interface. Which obviously isn't compatible with the existing Android client.

The best alternative is to use routing which wireguard is designed to do. Though if possible it's better to move the Wireguard gateway (Raspberry Pi with OpenWrt) to a separate subnet instead of 192.168.17.0/24. This way you only need to add a static route on the main router, not on all lan devices. It may also work if Raspberry Pi uses a 192.168.17.x address, but you risk problems with asymmetric routing.

1 Like