Right, so other than their respective WAN ports being connected to the same larger network, there is no direct connection between routers A & B? They are, for all intents and purposes, two separate LANs?
And the intended purpose of the tunnel is to allow clients (only wireless?) on router A to access clients on router B and the internet through router B's WAN connection? Anything else?
Exactly!
Yes. Any clients of A, wireless or wired, can go through the tunnel.
Ok, well a general config for a setup like you've described would be along the lines of:
Router A
config interface 'wg0'
option proto 'wireguard'
option private_key 'xxx='
option listen_port '51555'
config wireguard_wg0 'wgpeer'
option persistent_keepalive '25'
list allowed_ips '0.0.0.0/0'
option route_allowed_ips '1'
option endpoint_port '51555'
option endpoint_host '192.168.8.252'
option public_key 'U3CXLF55rU27j5s7Sh4kO1nKqgflVHeaqbfRyP4COjA='
Router B
config interface 'wg0'
option proto 'wireguard'
option private_key '0xxxI0Q='
option listen_port '51555'
config wireguard_wg0 'wgpeer'
option persistent_keepalive '25'
list allowed_ips '192.168.1.0/24'
option route_allowed_ips '1'
option endpoint_port '51555'
option endpoint_host '192.168.8.251'
option public_key 'DioqUp7BoOx+6dtQe90FKFF6eb82c25noKy5XZvevhY='
That assumes router A is using 192.168.1.0/24 for LAN connectivity. Router B should use a different subnet.
The wg interface can be added to the LAN zone on each router assuming all connected clients are trusted and (in real world usage) there is an appropriately configured firewall on the device responsible for passing internet traffic. If either of those was not the case then you would add the wg interface to the WAN zone or add it to a separate firewall zone and add appropriate forwarding rules.
Do you want to try amending your setup to match the above and check the tunnel is working as intended? If the transfer issue still persists then we can begin looking at other areas.
krazeh,
So the changes from the current configuration would be:
AFAIK allowed_ips needs to be 0.0.0.0/0 on both sides of the tunnel if there is going to be internet access, otherwise packets will be dropped at the more restricted side of the tunnel.
I will try
Nope, the packets will have a destination address for a machine on the other side of the tunnel, i.e. 192.168.1.x/32, so that will match the allowed IPs of 192.168.1.0/24 and be allowed into the tunnel.
I've gotten it going, though I had to add back a forwarding from LAN to WAN (which I had deleted in my original config) in order to make it work. Initial testing shows that the internet upload is now significantly closer to no-wireguard. I can also do "large" transfers over SSH without that breaking. I will test further.
One thing I notice is that even though Router A and B are pretty much identically configured, with exception of their LAN subnets, the automatically generated routing information is quite different. Router A sets the default route to wg0 but Router B does not. Odd!
root@WG_1e8b:~# ip route
default via 192.168.8.1 dev eth0.2 proto static src 192.168.8.252
192.168.1.0/24 dev br-lan proto kernel scope link src 192.168.1.1
192.168.2.0/24 dev wg0 proto static scope link
192.168.8.0/24 dev eth0.2 proto kernel scope link src 192.168.8.252
192.168.219.0/24 dev wg0 proto static scope link
vs
root@WG_264e:~# ip route # this is router A with WiFI LAN
default dev wg0 proto static scope link
192.168.2.0/24 dev br-lan proto kernel scope link src 192.168.2.1
192.168.8.0/24 dev eth0.2 proto kernel scope link src 192.168.8.251
192.168.219.0/24 dev wg0 proto kernel scope link src 192.168.219.1
Also, any thoughts about why my previous approach (of putting wg into it's own firewall zone) was failing? Why does putting WG into the LAN zone help?
This depends on the WG peer's options allowed_ips and route_allowed_ips.
This may be related to your runtime configuration:
iptables-save
As vgaetera says, this is all due to the options within the respective peers. As they both have route_allowed_IPs set to 1 then WG will create appropriate routing rules based on the content of allowed_ips.
On router A you have allowed_ips set to 0.0.0.0/0 so you are telling WG that you want all traffic to go through the tunnel, which is why it sets the default route to wg0.
On router B you have allowed_ips set to 192.168.1.0/24 so you are telling WG you only want traffic destined for that subnet to go through the tunnel. WG therefore only creates a routing rule for that subnet.
It may be that changing the WG/peer configs is what has solved the issue, rather than moving WG into the LAN zone. The reason I recommended it was to remove as many variables as possible to begin troubleshooting. Having WG in another zone shouldn't, in itself, cause the issues you saw.
If, for your specific setup, you need the WG interface in it's own zone then I'd start by doing that on one of your current test routers. Put the interface in a new zone and set up forwardings to/from the LAN and WAN zone. See if that has any impact. If not, then try it on the other router as well. If that also has no impact then you can begin looking at finetuning rules/forwardings etc.
This makes clear sense!
Thank you both for your help!
I will do some more testing...
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
The address is wrong. Should be 1.0/24 (for the whole network) or 1.1/32 (for one host).
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!
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. 
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 
) 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.).
The routes to allowed IPs on a wireguard interface are set up by /lib/netifd/proto/wireguard.sh
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
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.