[SOLVED] Wireguard, Interfaces and Assignments: can't reenable instance

[OmnomBánhmì]

So I had several Wireguard instances configured, on different ports, and things worked well. For testing I disabled one of the wireguard "servers". This instance wg1 stopped working, test completed. The other continued to work.

Now, in VPN > Wireguard > Local the box for wireguard1 is checked again, and the interface shows in Interfaces as wireguard1. It is enabled as far as the information available here says.

But, in Interfaces > Overview it is marked as "down", and in Assignments wg1 shows as being assigned to re0 (and a real MAC) instead of wg1 and 00:00:00:00:00:00. wg1 is not shown and not listed in the dropdown list for re-assigning. The interface wireguard1 did not have an IP address configured.

So even though it is an enabled instance (as per VPN , the interface shows, it cannot be used now that I turned it off.

How can I enable it again such that I can assign wg1 to the interface again, and it will actually work and show in VPN -> Wireguard -> List Configuration (or % sudo wg  show)?

Rebooting the machine, restarting all services, and disabling and re-enabling wireguard or the interface did not improve the situation. What have I missed? What to do now?

[OmnomBánhmì]

Short version, if you have more than one Local instance of wireguard, any Endpoint belonging to one of the servers must not have more than the TunnelIP address /32 assigned to it. If it has, like in 10.10.10.5/32 192.168.1.0/24 then this happens: the wg instance will not show in "List Configuration", it will not start, and there is no error message to be found, not even in "sudo wg show".

So fixing this is simple, check your endpoints if it happens to you. Once the wg instance comes up, you will see the "new" instance in Interfaces > Assignments.

So this is interesting, and I led myself be led by various tutorials available on the internet for getting into these troubles. They say to "restrict" the client after connection to accessing a certain network range, add the 192.168.1.0/24 range to the endpoint definition. That might work for single instance setups, but does not work for me with many.

(I guess I need to  read more on cryptokey routing and all the interfacec types involved.)