Specify outbound interface (priority) for WG
-
You could add a static route to the remote endpoint via the gateway you want but it would probably break the connection if that hoes down.
Though the other end could establish to a different WAN if configured for it and reply-to would kick in. So maybe a dyndns entry on a gateway group.Steve
-
@stephenw10 said in Specify outbound interface (priority) for WG:
You could add a static route to the remote endpoint via the gateway you want but it would probably break the connection if that hoes down.
That what I was trying out above and asking if there's another way to do it "right"?
->
... afterwards add a host-based route via WAN3 to the IP of the peer instance. But that's a rather "hammer-style" approach, as all other traffic to that IP would go out WAN3, too even if that's not wanted.
But
So maybe a dyndns entry on a gateway group.
On which side would that do what? Trying to get behind what you're suggesting :)
-
The dyndns client would have to be on the multiwan side running on a failover group with WAN3 as tier 1. The other side uses that hostname so that if WAN3 goes down it connects via one of the other WANs. There would be a delay whilst the dyndns updates and the other side resolves it gain.
Steve
-
@stephenw10 said in Specify outbound interface (priority) for WG:
The dyndns client would have to be on the multiwan side running on a failover group with WAN3 as tier 1. The other side uses that hostname so that if WAN3 goes down it connects via one of the other WANs. There would be a delay whilst the dyndns updates and the other side resolves it gain.
Ah now I understand where you're getting at. Right.
But how about getting the MulitWAN side to head out the right interface in the first place if not going via a manual static host route? And that one would break if the chosen WAN would break down. And with WG answering/initiating the connection via the wrong WAN initially the other side just responds to it and goes on.
Currently my setup is already:
- remote side is configured to connect to WAN3s IP address
- local side is configured for remote hosts IP (only one)
Remote side initiates connection on WAN3, local side responds via WAN1 and remote side recognizes that (somehow) and continues talking via WAN1 all the time. The state via WAN3 will expire after 1-2min and all talk is WAN1 (default WAN). When manually injecting a host route (before or after) that handles remote IP via WAN3 only then is WG able to really continue talking via WAN3 otherwise it switches to the default WAN almost immediatly. And manually adding a route isn't that nice ;)
That's why I was asking how one is supposed to run WG in MultiWAN when the default WAN isn't the one WG should connect via in the first place :)
-
Hmm, interesting. I would have expected reply-to on WAN3 to have caused the local side to reply on WAN3 if the remote side connects initially. But it is UDP and WG has no 'session'....
To do this you would need to be able to add static routes via a gateway group and you can't, yet, do that in pfSense.
You could potentially then select an interface(or group) in the gui to run it on in the gui and have it add the route.
That's not possible as far as I know in this initial release. Could be a feature request.
Steve
-
For inbound connections on Multi-WAN you may want to try setting a port forward on each WAN which redirects to 127.0.0.1 on the WireGuard port. That should trick pf into doing the right thing for matching the session and returning it via other WANs.
For outbound, not much you can do except setup a gateway group with the failover behavior you want and use that as the firewall's default gateway.
Remember: Upvote with the 👍 button for any user/post you find to be helpful, informative, or deserving of recognition!
Need help fast? Netgate Global Support!
Do not Chat/PM for help!
-
@jimp said in Specify outbound interface (priority) for WG:
For outbound, not much you can do except setup a gateway group with the failover behavior you want and use that as the firewall's default gateway.
Is there a way I can "stop" or "block" that WG instance from initiating the connection and "juts wait" for the other side to make the connection via the correct WAN? ;)
-
@jegr said in Specify outbound interface (priority) for WG:
Is there a way I can "stop" or "block" that WG instance from initiating the connection and "juts wait" for the other side to make the connection via the correct WAN? ;)
Don't fill in the Endpoint on the peer settings.
Then it can only respond, never initiate.
Remember: Upvote with the 👍 button for any user/post you find to be helpful, informative, or deserving of recognition!
Need help fast? Netgate Global Support!
Do not Chat/PM for help!
-
@jimp said in Specify outbound interface (priority) for WG:
@jegr said in Specify outbound interface (priority) for WG:
Is there a way I can "stop" or "block" that WG instance from initiating the connection and "juts wait" for the other side to make the connection via the correct WAN? ;)
Don't fill in the Endpoint on the peer settings.
Then it can only respond, never initiate.
AAH! That's one important piece of the puzzle
-
Would policy routing This Firewall in a floating rule be used to push WG tunnel traffic over a preferred gateway or gateway group? There seems to be some discussion on Reddit suggesting that this is also possible too instead of changing the default gateway.
-
@vbman213 said in Specify outbound interface (priority) for WG:
Would policy routing This Firewall in a floating rule be used to push WG tunnel traffic over a preferred gateway or gateway group? There seems to be some discussion on Reddit suggesting that this is also possible too instead of changing the default gateway.
Maybe, but that's always been a bit iffy -- It's worth trying, but if you do, carefully check the state table and packet captures to ensure that the traffic is exiting the correct interface with the correct address. A problem you might get into there is that it leaves, say, WAN2 with the source set to WAN1. Outbound NAT could work around that if it happens, but it's kinda ugly.
The problem is that pf policy routing influences packets that are already fully formed and on an interface, whereas the routing table also influences source address selection for UDP packets. So sure policy routing can change how a packet exits, but it can't change the address from which WireGuard sends the packet.
