[SOLVED] Multiple AllowedIps for clients fails

[Cahpheoj]

Hi,

I have set up a wireguard server on OpnSense 22.7.6 using wireguard-go (default) (see screenshot 1). Essentially, Tunnel Address is 10.4.0.1/24. I have multiple endpoints which have AllowedIps of 10.4.0.x/32 (see screenshot 2).

The issue is if I leave the AllowedIps of client set to 10.4.0.10/32, the wireguard interface comes up and everything is fine. However, as soon as I add 10.0.1.0/24 to the list of AllowedIps, the interface never comes up and I see this output when I try to bring wg up from the opnsense shell:

Code: [Select]

[#] ifconfig wg create name wg1
[!] Missing WireGuard kernel support (ifconfig: SIOCIFCREATE2 (wg): Invalid argument). Falling back to slow userspace implementation.
[#] wireguard-go wg1
┌──────────────────────────────────────────────────────┐
│                                                      │
│   Running wireguard-go is not required because this  │
│   kernel has first class support for WireGuard. For  │
│   information on installing the kernel module,       │
│   please visit:                                      │
│         https://www.wireguard.com/install/           │
│                                                      │
└──────────────────────────────────────────────────────┘
[#] wg setconf wg1 /dev/stdin
[#] ifconfig wg1 inet 10.4.0.1/24 alias
[#] ifconfig wg1 mtu 1420
[#] ifconfig wg1 up
[#] route -q -n add -inet 10.4.0.11/32 -interface wg1
[#] route -q -n add -inet 10.4.0.10/32 -interface wg1
[#] route -q -n add -inet 10.0.1.0/24 -interface wg1
[#] rm -f /var/run/wireguard/wg1.sock

I removed 10.0.1.0/24 from AllowedIps, `wg-quick up wg1` works fine and the interface comes up appropriately.

Code: [Select]

[#] ifconfig wg create name wg1
[!] Missing WireGuard kernel support (ifconfig: SIOCIFCREATE2 (wg): Invalid argument). Falling back to slow userspace implementation.
[#] wireguard-go wg1
┌──────────────────────────────────────────────────────┐
│                                                      │
│   Running wireguard-go is not required because this  │
│   kernel has first class support for WireGuard. For  │
│   information on installing the kernel module,       │
│   please visit:                                      │
│         https://www.wireguard.com/install/           │
│                                                      │
└──────────────────────────────────────────────────────┘
[#] wg setconf wg1 /dev/stdin
[#] ifconfig wg1 inet 10.4.0.1/24 alias
[#] ifconfig wg1 mtu 1420
[#] ifconfig wg1 up
[#] route -q -n add -inet 10.4.0.11/32 -interface wg1
[#] route -q -n add -inet 10.4.0.10/32 -interface wg1
[+] Backgrounding route monitor


And then I try to run the last `route` command:

Code: [Select]

route add -inet 10.0.1.0/24 -interface wg1

and I get the following error:

Code: [Select]

add net 10.0.1.0: gateway wg1 fib 0: route already in table

I've looked through the routing table and I don't see an entry associating 10.0.1.0/24 and wg1 interface. It's only associated with my lan network.

I don't know what to do at this point. This setup used to work before I upgraded to 22.7. It's been broken for some time and I'm not sure what the last working version was. I know I was on 21.x (forget the minor version).

How do I debug/fix this? I'm looking to have my subnet accessible to the client.

[Greelan]

You are going about it the wrong way.

If you want the “client” to access the LAN, add the LAN network to the allowed IPs *on the client* (not on the OPNsense endpoint config for the client), and also add a firewall rule on OPNsense on the WG interface.

See https://wiki.opnsense.org/manual/how-tos/wireguard-client.html

It’s expected that you are having a routing error because if the subnet you are adding is your LAN network, then of course that is already in the routing table.  By doing what you are doing, you are trying to tell OPNsense to access the LAN network IPs from OPNsense over the tunnel (ie at the client end), which is of course conflicting.

[Cahpheoj]

Thank you! That makes sense!

That seemed to be the issue as well. I suspect trying to test an alternative configuration, I had removed my LAN subnet from my *client device* configuration and I then looked at the router to find the problem.