wireguard/wireguard-go service doesn't start anymore after latest update (22.1.3)

[strarsis]

• I have read the contributing guide lines at https://github.com/opnsense/plugins/blob/master/CONTRIBUTING.md
• I have searched the existing issues, open and closed, and I'm convinced that mine is new.
• The title contains the plugin to which this issue belongs

Describe the bug
After updating OpnSense to latest release (22.1.3) from a quite recent release (one or two months old),
the wireguard-go service doesn't start anymore. It worked fine before the update.

To Reproduce

1. In OpnSense Web GUI, go to Lobby, note that the wireguard-go service is not started.

2. Try to start the wireguard-go service, note that it doesn't change its status to started, but stays stopped.

3. In OpnSense SSH, open the shell.

4. Manually try to (re)start the wireguard service, note the error messages:

[#] ifconfig wg create name wg0
[!] Missing WireGuard kernel support (ifconfig: SIOCIFCREATE2: Invalid argument). Falling back to slow userspace implementation.
[#] wireguard-go wg0
┌──────────────────────────────────────────────────────┐
│                                                      │
│   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 wg0 /dev/stdin
[#] ifconfig wg0 inet 10.0.0.9/24 alias
[#] ifconfig wg0 mtu 1420
[#] ifconfig wg0 up
[#] route -q -n add -inet 10.0.0.9/32 -interface wg0
[#] rm -f /var/run/wireguard/wg0.sock

Missing WireGuard kernel support (ifconfig: SIOCIFCREATE2: Invalid argument). Falling back to slow userspace implementation.

Running wireguard-go is not required because this kernel has first class support for WireGuard.

Quite a contradiction. Something probably went wrong during the wireguard interface configuration that doesn't have something to do with missing kernel support, but the service script assumes this (without inspecting the error message).

Expected behavior
The wireguard service should keep running and functioning after an OpnSense upgrade.

Relevant log files
In OpnSense GUI no logs can be found about the wireguard service.

Environment
OPNsense 22.1.3-amd64
FreeBSD 13.0-STABLE
OpenSSL 1.1.1m 14 Dec 2021

[mimugmail]

Can you change network in instance to /32?

[strarsis]

@mimugmail: Same error:

service wireguard start
[#] ifconfig wg create name wg0
[!] Missing WireGuard kernel support (ifconfig: SIOCIFCREATE2: Invalid argument). Falling back to slow userspace implementation.
[#] wireguard-go wg0
┌──────────────────────────────────────────────────────┐
│                                                      │
│   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 wg0 /dev/stdin
[#] ifconfig wg0 inet 10.0.0.9/32 alias
[#] ifconfig wg0 mtu 1420
[#] ifconfig wg0 up
[#] route -q -n add -inet 10.0.0.9/32 -interface wg0
[#] rm -f /var/run/wireguard/wg0.sock

[mimugmail]

10.0.0.1/32 shouldnt it be?

[strarsis]

@mimugmail: When no entries in Local are enabled, the wireguard service can be started.

There appears to be something wrong with the OpnSense interfaces;

LAN: igb0
LAN2: igb2
LAN3: igb3
VPN1: igb0
WAN: igb1

LAN, WAN and also VPN1 all got igb0 as network port.
This is probably wrong because VPN1 is the interface to be used by Wireguard, and igb0 is an actual physical network port?
Edit: The device for VPN1 is wg0 though.

[mimugmail]

This can be anything, too few infos like screenshots, interface assignments etc

[strarsis]

@mimugmail: I agree. How can I provide more information about this issue?

[strarsis]

@mimugmail:

Can you change network in instance to /32?

The OpnSense WireGuard documentation is ambiguous sometimes;

Do not use a tunnel address that is a /32 (IPv4) or a /128 (IPv6)

But in either case, with /24 or /32 – the WireGuard service (and tunnel) doesn't start.

[strarsis]

I think I found the reason - strangely that configuration had worked fine all the time until the last firmware update.
The Endpoint Allowed IPs contained the IP address of the router in local configuration.
Local:
OfficeRouter

Tunnel Address: [10.0.0.9/24]

Endpoint:
OfficeVpn:

Allowed IPs: [10.0.0.0/24] [10.0.0.9/32]

The correct configuration would be:
Local:
OfficeRouter

Tunnel Address: [10.0.0.9/24]

Endpoint:
OfficeVpn:

Allowed IPs: [10.0.0.0/24] [10.0.0.1/32]

10.0.0.1/32 being an example of another WireGuard peer (10.0.0.1/32).

@mimugmail: Yes, more information about the configuration would have been necessary to fix this issue.

The WireGuard service started correctly after changing the Endpoint Allowed IPs field.