Skip to content
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

Jump to bottom

FS#1358 - Wireguard interface and the wrong route to the ip of the peer #6385

Closed
openwrt-bot opened this issue Feb 14, 2018 · 7 comments
Closed

FS#1358 - Wireguard interface and the wrong route to the ip of the peer #6385

openwrt-bot opened this issue Feb 14, 2018 · 7 comments
Labels
flyspray

Comments

@openwrt-bot
Copy link

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!
@openwrt-bot
Copy link
Author

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.

@openwrt-bot
Copy link
Author

jow-:

Attach your /etc/config/network as well as the output of "route -n"

@openwrt-bot
Copy link
Author

Bluse:

Hi,

I do have a similar issue with setting up wireguard between two mesh routers that have a route by olsrd.
My request on the lede-dev list was not commented yet, so maybe you can try my patch and let me know if this works for you:

http://lists.infradead.org/pipermail/lede-dev/2018-February/011335.html

Greetings Thomas

@openwrt-bot
Copy link
Author

Bluse:

my patch has a major bug .. there is a "{" missing ... I will resend it.

@openwrt-bot
Copy link
Author

mikma:

Jo-Philipp Wich: I assume you either have duplicate default routes configured or overlapping scopes in your setup.

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)

...
if (!*res || route->mask < (*res)->mask)
*res = route;

Shouldn't it be:

if (!*res || route->mask > (*res)->mask)
*res = route;

The call to the function above is documented saying that it's supposed to find the best match, but is that really happening?

/* do not stop at the first route, let the lookup compare
* masks to find the best match */
interface_ip_find_route_target(iface, addr, v6, &r_next);

@openwrt-bot
Copy link
Author

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?

@openwrt-bot
Copy link
Author

nbd:

Fixed in r6437-1cd76e2d85

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
flyspray
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@openwrt-bot