VPN and routing bug?

[netshi]

I have no idea what was going on. I could not get the wireguard wg2.conf working at my remote site. It was working earlier and it went down suddenly and it would not go up. I rebooted the firewall and still nothing. I ssh-in and restarted wireguard and it says:

wg-quick: `wg2' is not a WireGuard interface

wg2 was not visible in the Interfaces / Assignment section on the web UI. I am not exactly sure what to do with the wireguard situation at this point.

Another issue that I have is at my main site, I have a route-based IPSec as my site-to-site backup (wireguard is primary). It is up, but it is not routing. I checked the route table both CLI and web UI and the CLI is showing the route is reachable via the wireguard site-to-site interface which was currently down because of the issue I am having at my remote site. The web UI was showing that the remote site is reachable via the ipsec1.

The version that I am running is 22.1.10_4-amd64 on both firewalls.

I rebooted the remote site and it seems IPSec does not start after a reboot. Thankfully the wg1 was up and I was able to remote in.

I rebooted the remote site again and wg2 went up, but won't connect to the main site. I rebooted the main site's OPNsense and the wireguard is now up. Why does it require several reboots to get the wireguard working?
Also, when the wireguard was down, why the routing table is still pointing to use the wireguard to forward the traffic instead of the ipsec site-to-site? It seems like OPNsense is blackholing itself.

In addition, on the web UI, the route is showing on both firewalls that the route is reachable via ipsec1 learned from BGP, but the forwarding is happening via the wireguard link. The wireguard BGP is stuck in an active state. In CLI, "netstat -r" shows that the route is reachable via wireguard.

When I logged in to FRR and checked the routing table, it shows that the remote site is reachable via the ipsec1 (via BGP). At the remote site, using the CLI, the "netstat -r" shows that the main site is reachable via ipsec1. The remote site's FRR also shows the main site is reachable via ipsec1.

I am located at the main site and ran a traceroute from my workstation and sure enough, it took the ipsec path; however, the logs showing in Live View is wireguard as an interface. The traceroute from the remote site is taking the IPsec path.