New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
FS#1358 - Wireguard interface and the wrong route to the ip of the peer #6385
Comments
jow-: A host route to the peer is added to prevent the tunnel from collapsing in case the default route is replaced to route via the tunnel instead. This is by design and usually causes no problem. I assume you either have duplicate default routes configured or overlapping scopes in your setup. |
jow-: Attach your /etc/config/network as well as the output of "route -n" |
Bluse: Hi, I do have a similar issue with setting up wireguard between two mesh routers that have a route by olsrd. http://lists.infradead.org/pipermail/lede-dev/2018-February/011335.html Greetings Thomas |
Bluse: my patch has a major bug .. there is a "{" missing ... I will resend it. |
mikma:
What does scope mean in this context? I looked in the source code and it seems to use the least specific route when calculating the source route. I also verified the behaviour by configuring a static route covering the wireguard peer that's more specific than the default route, but netifd ignored that route. The code below in interface-ip.c looks wrong.
static void
__find_ip_route_target(struct interface_ip_settings *ip, union if_addr *a,
bool v6, struct device_route **res)
Shouldn't it be:
The call to the function above is documented saying that it's supposed to find the best match, but is that really happening?
|
mikma: I have verified that my idea for a patch indeed does solve the bug I described. I'm including a patch for netifd tested with version 650758b16e5185505a3fbc1307949340af70b611 which used in branch lede-17.01. It still won't pick up routes inserted by routing protocols such as babeld. As a work-around you need to add a static route to the wireguard endpoint. BTW is really a host route necessary if "Route Allowed IPs" isn't enabled for the peer? |
nbd: Fixed in r6437-1cd76e2d85 |
mibofra:
I am using trunk version of openwrt in two routers. Everything up-to-date
Try to setup wireguard with uci or luci, and put the address of the other peer in the configuration.
The result is that when the interface is set up, it is set up a route to the ip of the peer, arbitrarily, to a router in lan.
Why I am saying arbitrarily? Because on a router I have a lan, and it is assigned the lan router. On another router I have to lans, and it is assigned the router of the second lan
I really have to try with three lans...
So, for example I am playing with it, with two openwrt clients (the openwrt routers). 192.168.219.13 is the address of peer 1 and 192.168.219.18 of peer 2. That is the result:
on peer 1, when the wireguard interface goes up: 192.168.219.18 via 192.168.42.1 dev br-lan2 proto static
on peer 2, when the wireguard interface goes up: 192.168.219.13 via 192.168.34.2 dev br-lan proto static
The route of the openvpn network is: 192.168.219.0/24 dev tun0 proto kernel scope link src 192.168.219.13 (on peer 1, src 192.168.219.18 on peer 2)
The result is that after the set up of the wireguard interface, both can see the whole network, but not each other, because they are searching them on the lans...
For this reason, I address the netifd helper of wireguard, because it is duty of netifd to bring up the interface, but I really have to verify the source code of the helper.
I guess it is a bug, if not, why decide to create another route for the peer? I think obviously if you want to setup the vpn, at lease the peers can see each other through an interface. Whatever the kind of the interface (pptp interface, tun, tap, pigeons with ip on qrcodes...) and the network (lan, wan, vpn...).
So this make for me nosense to add another route for the peer. If need, or you can ad another option, with the possibility to completely set up the route for the ip of the peer, or I think it is sufficient to add a static route with uci/luci or manually, to reach the same goal.
I really hope that I am not the only one with this bug, and I really hope that will be repeatable to check it.
Thanks in advance!
The text was updated successfully, but these errors were encountered: