WireGuard site-to-site Issues
-
I followed this configuration recipe for configuring site-to-site with WG and I was not able to ping across the VPN. However, the VPN establishes and both sides report a handshake.
https://docs.netgate.com/pfsense/en/latest/recipes/wireguard-s2s.html
I notice at the end of this document it says when you assign the WG interface, a gateway is automatically created which you can use for policy routes. I noticed that on both my SG-5100 and XG-1537, that a gateway was not created when assigning WG interface after creating the tunnels and peers on both ends. Both firewalls on 21.05 firmware.
The article/recipe also doesn't mention anything about NAT, but I read a few other WireGuard tutorials and they mention configuring NAT outbound on your LAN subnets to use the WG interface.
-
@iamarobot WireGuard in 2.5 is not recommended, it was removed in 2.5.1
WireGuard package in 2.5.1 and up is experimental.
-
@tirsojrp Thanks for the reply.
I'm on firmware 21.05 (is that what you meant?) and I know it's experimental. I wasn't using for production, just to test. I wanted to know if anyone else has a similar problem or solution. Have a great weekend.
-
@iamarobot
You need to make your own gateway and routes now if using the new plugin. -
@brians Hello,
It doesn't seem to let me make a gateway. tun_wg0 doesn't seem to be presented as an interface that I can make a gateway for.
Scratch that, I'm dumb. I can see that I just have to literally add it as an interface in assignments.
-
One other thing to keep in mind, if you use Dual WAN there doesn't seem to be a way to specify which WAN interface to bind to, therefore it binds to the default gateway. For example I have WAN1 and WAN2 in a gateway group. WAN1 is tier 1, WAN2 is tier 2. I wanted to use the VPN on WAN2 but it will only pass traffic out through WAN1 even if the tunnel is established while using the IP of WAN2.
-
@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
