pfSense

Jim Pingle wrote:

That's the expected behavior. By adding it as an Allowed IPs entry you told the system you wanted that traffic routed to WireGuard/that peer.

Without wg, if my PC is on 10.10.0.0/16, and I attempt to connect to 10.20.0.0/16, my connection will route through pfSense, and route properly to the 10.20.0.0/16 subnet.

With wg, if I setup a peer with wg allowedips to 10.10.0.0/16, 10.20.0.0/16, the original connection above still functions perfectly. In this case, wg still does not hijack the routes.

Even if I have a peer connected with allowedips 10.10.0.0/16, 10.20.0.0/16, I can still connect from 10.10.0.0/16 to 10.20.0.0/16 on my PC, and have my packets be routed through pf normally.

I expect wg to hijack allowedips (routes) on the device that is connected to the tunnel, and it seems to do this perfectly.

However, if I need a static route (System > Routing) to get back to the correct network, wg is hijacking that route without any peers using the tunnel, essentially locking you out of the firewall as soon as you click Save, because pf no longer has the correct route to return packets (sending to wg interface instead). This behavior seems to be limited only to entries in the static routes table in System > Routing, which is why I'm still confused.

Seems like you have a flawed configuration/design issue there but it's hard to tell without more information. Post on the forum for a more in-depth discussion.

Allowed IPs sets up routing to a peer, and that is working as intended. If you are trying to do something more advanced like having multiple paths to a peer, you're likely approaching the problem incorrectly, but this isn't the place to discuss design issues.