Thanks for that.
So I went ahead and just removed the mangle rule and…nothing negative happened. I was following along from some research and chatgpt and saw both in example configurations. The route rule on it’s own (with the separate routing table) is working fine, and I removed the connection mark exclusion from fasttrrack, and there’s no performance hit now (not sure if you saw I mentioned that before, but I have also seen that problem with fasstrack in the past with ipsec so it stood out as the likely cause immediately)
Indeed in this case, I wish to send the entire subnet 192.168.110.0/24 via the tunnel. I believe I now have that
I have 3 other subnets in their own VLANs with associated WiFi config:
192.168.1.0/24
192.168.100.0/24
192.168.120.0/24
These are ticking along nicely, too. I believe that I have avoided any issue there by creating the separate routing instance and only creating routes applicable to the 110.0 (GUEST) Subnet:
The config is now:
/interface wireguard peers
add allowed-address=0.0.0.0/0 endpoint-address=x.x.x.x endpoint-port=yyyy interface=wg-nordvpn name=nord-peer persistent-keepalive=25s public-key="<pubkey>"
/routing table add name=wg-nordvpn fib
/ip route add dst-address=0.0.0.0/0 gateway=wg-nordvpn routing-table=wg-nordvpn
/routing rule add action=lookup table=wg-nordvpn src-address=192.168.110.0/24
/ip firewall nat add chain=srcnat src-address=192.168.110.0/24 out-interface=wg-nordvpn action=masquerade
Thank you for explaining the nuances around wireguard and how to handle those. In this case, having a fallback to the regular routing table is fine, and probably preferable. Bundling the traffic over a VPN is just a nice to have in this case, and largely more an experiment in Wireguard 