Specify outgoing interface for wireguard tunnel
-
I have a multiwan setup with a backup LTE modem. Currently I am using openvpn for the backup site to site tunnel since I can specify the outgoing tunnel interface.
Can wireguard be configured to initiate a tunnel over a specific interface as well?
Thanks,
Devan
-
@ddbnj One possible solution:
- Create a static route (/32 for IPv4 endpoints or /128 for IPv6). This is a "host" route, because it is scoped to a single address (/32 or /128). So basically you're telling pfSense, "hey if you need to reach endpoint 178.43.2.4, only use WANGW".
-
@cmcdonald That is cool idea I will try this weekend.
-
Well, I couldn't wait.
My setup threw a few wrenches into the concept. The endpoint for the tunnel is dynamic and is updated via DNS.
When making a static route, it would not accept a FQDN.
The workaround involved a few steps.
At the target end, create a new FQDN specific for the Wireguard connection over LTE. Set up DDNS on pfsense to keep it up to date.
On LTE modem side
create usual Wireguard tunnel and peer using new LTE specific domain name.On LTE modem side, create a firewall alias (to be used in static route) pointing to new LTE FQDN
Finally on LTE modem site, create a static route to alias using LTE gateway.
This way, my FIOS wireguard tunnel uses the normal WAN since it's FQDN endpoint is different that the LTE wireguard tunnel FDQN.
(Edit: I don't think this works)
-
Yea, I don't think it's working.
The routing alias translates the DNS result and routes all traffic (as it should) out the WAN gateway. As long as the IP endpoints are the same, I can't make a route specific for the outgoing requests just for LTE.
-
Since my outgoing WG peer on FIOS has the same destination IP as my outgoing Wireguard peer on LTE, the route solution above doesn't work. I'm not getting any states on the LTE interface. I was fooled, I think by ICMP redirects which made it seem all gateways were up.
-
@cmcdonald Wireguard ignores my static routes, even after a reboot. It seems to always use the default route. Might be a bug? Btw, thanks for your work with Wireguard.
