WireGuard site-to-site Issues
-
@iamarobot The only way to force WireGuard out a particular interface currently is to create a static host route (i.e. a /32 or /128 route pointing at the remote WireGuard peer endpoint IP) out a particular gateway.
-
@theonemcdonald yes this is what I've done, but the route does not persist on reboot. Looks like the tun_wg0 is being loaded too late so the rules fail as the gateway interface doesn't exist, and it's killing suricata from auto starting as well.
-
@propercactus You'd do something like this:
where WANGW is the gateway you intend WireGuard to ride over, and the destination network is the peer endpoint in question. That route should persist at reboot as it has nothing to do with WireGuard or the package
There is a fix that I'm testing that does address static routes not persisting when the gateway is a WireGuard interface, but that's a completely separate issue.
-
@theonemcdonald said in WireGuard site-to-site Issues:
There is a fix that I'm testing that does address static routes not persisting when the gateway is a WireGuard interface, but that's a completely separate issue.
Is it a seperate issue? Shouldn't my gateway be going out the WireGuard interface? It's no good going out my REDWAN
-
@propercactus There are two different layers here, you've got the outer WireGuard transport and the inner tunnel transport. If you want the outer transport to use a specific gateway, you'd do what I propose in my last post. This has nothing to do with WireGuard or the WireGuard package.
It sounds like you're talking about this issue https://github.com/theonemcdonald/pfSense-pkg-WireGuard/issues/122 which is unrelated to the above...as in this case, you're creating a static route pointing to an endpoint accessed via the tunnel (the inner layer).
-
@theonemcdonald I'm totally confused. I should route my traffic to the gateway that has nothing to do with the WireGuard tunnel at all?
-
@propercactus It depends on what you're trying to accomplish.
Like all VPN protocols, there are two layers (well there could be more but let's ignore semantics for a moment). You've got the outer layer (i.e. this is WireGuard UDP traffic communicating back and forth, handshakes, etc.) and you've got the inner layer which is the encapsulated packets of the tunnel network..that is, the 'virtual' IP network peers are using to communicate with each other.
If you are trying to nudge the outer layer to leave pfSense using a certain gateway (like if you've got a dual WAN configuration and you want WireGuard traffic to only leave via say WAN2 instead of WAN1), you'd create a static route that pushes traffic to the remote peer endpoint out WAN2. Otherwise, the outer layer is going to track the default IPv4 and IPv6 gateway assigned to pfSense itself.
-
@theonemcdonald said in WireGuard site-to-site Issues:
Otherwise, the outer layer is going to track the default IPv4 and IPv6 gateway assigned to pfSense itself.
Oh yea it's already sending the outerlayer (UDP packets over 55553) out the default gateway thats no issue.
I then create a gateway for the inner part that routes using the WireGuard interface to the remote 10.128.128.2/32 tunnel address in Azure. That's the one that doesn't persist on reboot.
Is that the bug you mention?
-
@propercactus Yes that is the bug.
-
@theonemcdonald gotcha, well that's good that it's known at least.
-
site to site does not pass traffic to subnet but only to wireguard tunnel itself.
kind of uselessconfirmed bug
-
@jimbohello yup I've switched to IPsec I can't lose connectivity to the stuff behind the tunnel for any given reboot.
-
M mikee referenced this topic on
