Problem with data transfers through wireguard tunnel

So I have done some experimentation and can see the cause of the performance problems, though I do not fully understand.

When I do automatic routes using route_allowed_IPs, I get full "upload" performance (roughly 9Mb/s).

My original method of doing routes was manual.

ip route add default via 192.168.219.2 dev wg0  table 99
ip route flush cache
ip rule add from 192.168.1.1/24 table 99

This had the problem, as described previously, of uncharacteristically slow "upload" performance, roughly 1/8 of the expected.

The following is very similar but matches the good speed of automatic routing.. It does routing based on input interface rather than src IP address.

ip route add default via 192.168.219.2 dev wg0  table 99
ip route flush cache
ip rule add iif br-lan lookup 99
1 Like

The address is wrong. Should be 1.0/24 (for the whole network) or 1.1/32 (for one host).

1 Like

Which file runs to configure routing when a wireguard interface is brought up and route_allowed_IPs is set?

It looks like you are going in the wrong direction.
It would be easier to help if you explain what you want to achieve and why you are using policy-based routing.

I'd still love to know where the wg routing is set up. I may be going in the wrong direction, but I am happy to learn from what is being done well already!

My goal is to have two routers, call them H and W, in different locations. When I connect to H, I have access to devices on the LAN of W as well as the internet from W. And symmetrically when I connect to W, I get access to the devices on the LAN of H as well as the internet from H.

Policy based routing will do this for me. I am also open to other alternatives if you want to propose them!

1 Like
uci set network.wgpeer.route_allowed_ips="1"
uci add_list network.wgpeer.allowed_ips="0.0.0.0/0"
uci add_list network.wgpeer.allowed_ips="::/0"
uci commit network
/etc/init.d/network restart

Since it's a Kernel module, it could be "direct" - if you will (i.e. it puts the routes into the Kernel). It does have to keep track of the routes and keys related to them after all. :bulb:

Hope that helps with your "nuts and bolts" question...that's not quite related to making things work.

I personally setup my routes and tables manually (in UCI syntax, of course :smiley: ) wihtout the PBR package or checking "route allowed IPs" (especially necessary of some of your tunnels are different ad-hoc Internet VPNs, some traffic can't go to a streaming service, etc.).

2 Likes

The routes to allowed IPs on a wireguard interface are set up by /lib/netifd/proto/wireguard.sh

4 Likes

This doesn't work if done on both ends. Since route_allowed_ips sets the route for 0.0.0.0/0 to go through the wg interface on both routers, the packets make it to the other router and then just head back through wg.

That is why I originally went with PBR.

I would also ideally like the router itself to be able to communicate directly with the internet, not via WG

1 Like

Move the VPN interface to a separate routing table:
https://openwrt.org/docs/guide-user/network/routing/pbr_netifd

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.