I have a weird proble, that I can’t wrap my head around. I have a VyOS 1.3.5 instance with two Wireguard tunnels. I have bridge interface set up (mainly to have spare ethernet ports) for outgoing traffic. My network is multihomed and there are alternative routes to the remote VPN endpoints. The problem is, wireguard traffic chooses the alternative route even though I have explicitly set static routes for remote VPN endpoint via the bridge interface… I also tried setting local-route policy and use a separate routing table with it but nothing works… the traffic goes thro eth0 interface as even if it is hardcoded or something… there is no even route via this interface.
The network went through multiple iterations with different versions of VyOS and switching 3-4 ISPs over last 3 years and it was working reasonably fine for the most part. The VPN tunnels in question supposed to serve as backup and I’ve only recently noticed that they are not functioning when I needed to disconnect the primary provider for hardware replacement, so it is very hard to trace back changes to configuration at this time since it is unknown when it stopped working…
Is anyone aware of any similar issues with wireguard? Any help is appreciated.
I indeed use “that thing” … I will look into this post in more details… I had issues with local IPv6 addresses in the past and using ::/0 was the workaround at the time. I suppose something has changed in the last couple of years.
Yup, you have that allowed-ips multiple times. That’s not how Wireguard works, think of those “allowed-ips” are more of a “wireguard, route these networks”. You can’t have more than one default route active at a time. This isn’t a VyOS thing, it’s a Wireguard thing.
Once you fix that up, you might have other issues (I haven’t examined your config in detail) but fixing that up will get you much further.
They are on different interfaces, so it should be fine… actually, while tinkering with configuration of one of the tunnels, I switched to more specific IP ranges and then reverted back to 0.0.0.0/0 thing… and this tunnel started working properly… then I rebooted the router and the second tunnel started working properly again, so it sems that there may be a bug related some lingering state after all. I remember in the past there were several occasions, when I would copy a configuration, then remove it and apply it again… that may be one of those cases…
…but thanks for your tip anyway - it actually helped to get to the bottom of it
Sorry, you’re right, they’re on different WG interfaces, so that won’t have been the problem as you rightfully point out.
I still think that 0.0.0.0/0 probably isn’t what you want, unless you’re really expecting to have the entire Internet come in via that Interface at some stage. Which given the config I guess is possible. But yea.