Is WireGuard presently limited to two tunnels?

[whit]

After success with two tunnels, trying to add a third, but while ifconfig shows wg0 and wg1, there's no wg2 as there should be now. Is this a limitation in the current implementation here, or have I missed something?

[mimugmail]

Try via console:
/usr/local/etc/rc.d/wireguard restart

And you'll see the error (in your configuration).

Tunnels are not limited.

[whit]

Thanks for the suggestion. It reveals nothing:

root@OPNsenseFL1:~ # /usr/local/etc/rc.d/wireguard restart

• rm -f /var/run/wireguard/wg0.sock
• rm -f /var/run/wireguard/wg1.sock
• wireguard-go wg0

INFO: (wg0) 2019/09/19 15:37:00 Starting wireguard-go version 0.0.20190805

• wg setconf wg0 /tmp/tmp.6RZWn0s6/sh-np.V0lHXz
• ifconfig wg0 inet 10.222.0.15/32 10.222.0.15 alias
• ifconfig wg0 mtu 1420
• ifconfig wg0 up
• route -q -n add -inet 10.222.0.1/32 -interface wg0
• route -q -n add -inet 192.168.1.0/24 -interface wg0
• route -q -n add -inet 172.25.0.0/16 -interface wg0
• route -q -n add -inet 172.17.0.0/16 -interface wg0
• Backgrounding route monitor
• wireguard-go wg1

INFO: (wg1) 2019/09/19 15:37:01 Starting wireguard-go version 0.0.20190805

• wg setconf wg1 /tmp/tmp.AMDHjvxD/sh-np.B7mD5q
• ifconfig wg1 inet 10.0.222.15/32 10.0.222.15 alias
• ifconfig wg1 mtu 1420
• ifconfig wg1 up
• route -q -n add -inet 10.0.222.15/32 -interface wg1
• route -q -n add -inet 10.0.222.110/32 -interface wg1
• route -q -n add -inet 172.25.10.0/24 -interface wg1
• route -q -n add -inet 172.16.0.0/16 -interface wg1
• Backgrounding route monitor

And it stops there, no error, and nothing about the wg2 interface that should be there.

Looking in /usr/local/etc/wireguard, there is only wg0.conf and wg1.conf. Yet the VPN: WireGuard screens on OPNsense show both the Local and Endpoint setups that should produce wg2.conf.

Whit

[whit]

Ah! I see the problem. It is necessary not just to hit Save in both Local and Endpoint individual setup pages, but also the Save again on at least the Local page listing each of the Local endpoint -- even though they've already been saved individually. So it's not the Save button for the individual Local and Endpoint setup pages which builds the config file, but the Save button for the page which lists all the Locals.

Perhaps that would be clearer if it were labelled "Apply" rather than "Save"?

Best,
Whit

[whit]

There is something glitchy in that though. It initiated the third tunnel with those "extra" Save options, but it dropped one of the existing tunnels. Going through the pages again for the now-dropped tunnel, pressing Save for the individual as well as group pages, got us back to having three tunnels running.

Again, that was an established tunnel. Nothing was changed on it. And nothing was changed on it since then either. There might be some timing dependency as it starts multiple WireGuard tunnels that can cause it to fail on one.

Whit

[mimugmail]

Sounds like /24 in Tunnel address instead of /32? Have you checked OPNsense Docs for this? I added a note there some weeks ago.

Every save in every tab should trigger a restart.

[whit]

Each address is/was a /32 for the wg interfaces.

The problem where I finally got the 3rd tunnel up and it dropped the 2nd in doing so, until I pressed all the "Save" buttons again without editing anything, looks like a separate thing. But since that firewall is in production, I can't go bouncing the tunnels up and down to see how replicable it is. Might have been a one-off event.

[mimugmail]

For me, it sounds like /24 instead of /32. If you can reproduce it some more times I can have a look, but please understand that I don't have the time to build a lab just trying to reproduce (which I did some weeks ago for the /32 thing which was just lack of documentation)

[whit]

Honestly, I never set any of these addresses as a /24. Always a /32.

Is your theory that setting it as a /24 would block the writing of the config file for the wireguard instance? It wasn't that, but something obviously prevented it from being created until the Save button on the main page -- not those one the "inside" pages -- was pressed. I'll try this again on our current spare system, which we haven't placed into its future DR role yet.