Messages

Two addresses is what you configured - one SLAAC address and one DHCPv6 address.

If you want only DHCPv6, remove 'slaac' from RA Mode.

If you want only SLAAC, remove 'slaac', add 'ra-stateless' and remove start / end address.

That's not possible, by design. When enabling SLAAC, most clients use privacy extensions, meaning they randomise their interface identifier (lower 64 bits of the IPv6 address) for outbound connections.

If you really need to identify individual clients, you have to disable SLAAC and use stateful DHCPv6 (which is not supported by all clients).

You could look into identifying clients by their MAC address, but many randomise that, too.

If you need certain rules for certain groups of clients, it makes more sense to assign them to separate (V)LANs.

A /56 would be abcd:efgh:ijkl:mn00::/56. Are you sure you actually get a /56? Check Interfaces / Overview / WAN / Details / Dynamic IPv6 prefix received.

If you get a /56, setting the prefix ID to 0 or 1 (no leading zero) should result in abcd:efgh:ijkl:mn00::/64 / abcd:efgh:ijkl:mn01::/64.

Then gateway monitoring is probably misconfigured. Check the routing table for 8.8.8.8. Make sure it isn't configured as a DNS server in System / Settings / General.

WireGuard is stateless. If the keys don't match, no traffic passes the tunnel. But there is no "login" or "connection" which could fail. That's by design.

If that ping fails, how do I know it's a key mismatch on the VPN server as opposed to a rule on OPNsense preventing data from going out?

Since this is traffic originating from OPNsense itself, you would have to accidentally create a firewall rule which blocks outbound traffic. And then you would see blocks in the firewall log.

I have 8.8.8.8 as the Monitor IP in the Wireguard interface. It showed the Wireguard interface as green

The interface was "green" or the gateway? Gateway monitoring creates a static route for the monitor IP to prevent the pings from taking other routes, so it should definitely show the gateway as down.

I'm not talking about the WAN gateway or the WireGuard status. You can set up an additional gateway monitor (System: Gateways: Configuration) for the WireGuard tunnel. Dpinger then pings a monitor IP of your choice through the WireGuard tunnel. If the tunnel stops passing packets, the ping fails.

-> Dort ist bereits ein WG-Interface mit 10.0.10.2 konfiguriert.
-> Dort sind Pass Regeln Any -> 10.0.10.0/24 & Any->10.0.11.0/24 & Any -> NonLocal definiert
WireGuard(Group) hat keine Regeln.

Hast Du in der Regel "Pass Any -> 10.0.11.0/24" reply-to explizit auf das das Gateway 10.0.10.1 gesetzt? Das ist erforderlich, damit die Antworten des Webservers auch wieder durch den Tunnel zurückgeroutet werden.

Die "Force Gateway"-Regel greift nur bei Verbindungen, die vom Webserver initiiert werden (z. B. der curl-Test).

Das stellst Du nicht in der Gateway-Gruppe ein, sondern direkt bei den einzelnen Gateways (dort Advanced Mode aktvieren).

Grüße
Maurice

You can assign the wg interfaces and configure gateway monitoring.
Or use Monit if you want email notifications.

Cheers
Maurice

Looks good to me.

On "Rogers" (DHCP), you have IP address 99.227.251.81/23 and gateway 99.227.250.1.
On "WAN" (PPPoE), you have IP address 70.50.43.217/32 and gateway 142.124.37.248.

Can you elaborate what you consider "incorrect" or what issue you're observing?

Cheers
Maurice

You'll need two WireGuard instances on OPNsense for this. Peer selection in wg is based on the destination IP address, as configured in the 'allowed IPs'.
If you want to use both VPS nodes for Internet access, 'allowed IPs' must be 0.0.0.0/0 for both peers. But you can't have two peers with the same allowed IPs in one wg instance.

Cheers
Maurice

Hast Du auf dem WAN-Interface des VPS auch ein Outbound-NAT für 10.0.11.0/24 konfiguriert? Falls nicht, dann gehen die vom Webserver gesendeten Pakete mit privater Quelladresse ins Internet, werden daher gefiltert und kommen nicht beim Client an.

Grüße
Maurice

The OUI database is included in the OPNsense core package. As far as I'm aware, the only intended way of updating it is updating OPNsense itself.

Cheers
Maurice

Definitely one of the more bizarre threads around here.

Just as a PSA for newbies stumbling over this: Do whatever you want in your own private networks, but the ideas presented here are pretty fringe and in no way best practice or widely accepted.

(First and only comment.)

Cheers
Maurice

Most systems ignore explicit routes advertised in RAs, even if they do accept RAs and use them for SLAAC, setting the default route etc. I don't think FreeBSD / OPNsense is an exception (let me know if I'm wrong).

That's where reality differs from the RFCs. While it seems like a good idea to autoconfigure specific routes from information in RAs, most vendors have decided not to implement this.

Cheers
Maurice