Wireguard Selective Routing Instructions - Question

[Salty72]

Hi,
I'm following the wireguard selective routing instructions on the docs.opnsense.org website.
Step 9 has me confused; as in, I would like to understand the purpose of it.

Step 2: Configure local peer instructs the Tunnel Address to be /32. This makes sense in that a specific IP is assigned to the VPN local peer (e.g. 10.0.0.2/32) and routing is disabled (assuming that the firewall rules will take care of it).

Step 2 and 6: Creates a gateway on the VPN subnet. (e.g. 10.0.0.1/32)

I performed all the steps 1-8.
At this point, my opnsense server can ping the gateway (10.0.0.1/32) but cannot ping a remote peer (10.0.0.3/32). A local LAN host can ping the gateway (10.0.0.1/32) and a remote peer (10.0.0.2/32). The remote peer can ping my defined gateway (10.0.01/32) and a host in my LAN (192.168.0.x) but cannot ping my local peer (10.0.0.2/32).

Step 9: Configure routing instructions has me confused.
It states that all outbound packets originating from the VPN address (10.0.0.2/32) with an destination of the VPN network should be directed to the VPN gateway (e.g. 10.0.0.1/32).

Couple of questions:
1. Where did we define the VPN network being used in Step 9? Since we specified the VPN local peer in step 2 to be 10.0.0.2/32 and the interface picks up the IP and subnet from the VPN local peer, wouldn't the VPN network be 10.0.0.2/32?
If yes, why are routing a packet from 10.0.0.2/32 to 10.0.0.2/32 to a gateway in the VPN tunnel?
If no (and the VPN network is identified correctly e.g 10.0.0.2/24), is this rule for allowing the firewall and NAT'd clients to access the VPN?

Adding the routing rule in step 9 did not make a difference to my ping issues prior to step 9.

2.  Assuming that I'm not performing NAT (other peers can route packets for my subnet back through the VPN tunnel), I would not create a NAT rule (step 10). Does step 9 provide any purpose/value if I'm not creating the NAT rule (step 10)?

Thanks,

[Greelan]

Step 9 has the destination inverted, so it behaves differently to what you describe.

Basically it’s replicating the force gateway rule for WAN, to ensure that packets coming from the WG interface IP go out the right gateway. See this (lengthy) discussion: https://github.com/opnsense/core/issues/5329.

Should really only be an issue for services on OPNsense itself that are intended to use the tunnel (eg unbound in the issue linked above).