Probably you have some network related issues such as packet dropping.
Check from the client:
mtr -wbc 100 example.org
mtr -wbc 100 wg_endpoint
mtr -uwbc 100 wg_endpoint
They have (pretty much) the same configuration. The configuration is pretty much taken from the wiki pages.
Ok, on your test routers can you change the LAN subnets so they are different to each other? And on one of the routers change the allowed_ips for the WG peer to the subnet you've allocated to the LAN on that peer.
Then on both routers add the wg interface to the LAN firewall zone and delete:
config zone 'vpn'
option name 'vpn'
option input 'ACCEPT'
option output 'ACCEPT'
option forward 'ACCEPT'
option masq '1'
list network 'wg0'
config forwarding 'lan_vpn'
option src 'lan'
option dest 'vpn'
config forwarding 'vpn_wan'
option src 'vpn'
option dest 'wan'
This is by no means a large data chunk.
If you can reproduce the issue with 100% result, then it's likely some misconfiguration, e.g. MTU.
Otherwise, it should be a transient problem related to unstable connectivity.
1 Like
264e router changes:
LAN is now 192.168.2.1/24
network.wgpeer.allowed_ips='192.168.1.1/24' '192.168.219.1/24'
This means I can only talk over wg to the other router itself and clients on the other router's LAN. No internet access through the tunnel.
On both routers I have deleted the special vpn zone and the two forwardings related to that zone. I have also added wg to the firewall zone of the LAN. I have not added wg to the interface bridge for LAN, see photo here
The two routers still build a tunnel. Because of the new allowed_ips, routing through the tunnel to the internet is not possible.
Anything else you would like me to do?
To note: the previous config with the same LAN numbering works fine because there is a NAT which happens as the traffic enters the tunnel, so that the src address appears to be wg router IP address.
Has it had any impact on the issue? Can you post the updated output of the commands I posted earlier in the thread?
Sorry for the delay.
Post changes I am struggling.
I am connected my VPN client (264e) network, which now has a LAN of 192.168.2.1/24. My traffic makes it to my VPN server (1e8b) through the tunnel, but on the server the packets have SRC=192.168.2.101 which is my laptop address (the original config had a special vpn zone which did masquerading, and so the source address was always the client router wg ip).
https://openwrt.org/docs/guide-user/services/vpn/wireguard/client describes clients putting the wg interface in the WAN zone "to minimize firewall setup". My wg interfaces are both in the LAN zone right now.
Right, lets go back to basics. What is the point of the WG tunnel in your LAN? Why have you set it up? What is it intended to achieve?
I have two routers, A and B. I want wifi clients on A to have all their traffic exit to the LAN and/or internet of B, via the tunnel. This works perfectly except..
I have two issues:
- When I transfer "large" chunks of data (via the test-LAN wg tunnel) using ssh, the ssh connection breaks. A smaller transfer works fine.
- When I try a standard internet speed test (via the test-LAN wg tunnel), I find the download speed matching what I would expect, while the upload speed is 1/10 of what I would get if I bypassed the tunnel
My suspicion is that there is some sort of MTU issue which is causing problems with "large" transfers from my LAN through the wg tunnel, but I may be quite wrong.
Note: "large" here is used relatively. I am not talking about HUGE transfers.
And what is the overall setup of the larger network? How are routers A and B connected? Do they connect to the internet over different routes? Guessing from your earlier config files there's at least one more router in the larger network?
1 Like
Both my test wireguard routers, A and B, have their WAN ports plugged into a test LAN (that is the 192.168.8.1/24 network from the config). They are all on the desk next to me for easy access 
. They connect to the internet over one connection.
I have a separate pair of wireguard routers, which are in two different locations and connected to different ISPs over the public internet. They have the same problems as in my test setup, which is why I built the test setup.
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:
- Automatic routing using route_allowed_ips (vs. originally manual routing)
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.
2 Likes
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?
1 Like
This depends on the WG peer's options allowed_ips and route_allowed_ips.
This may be related to your runtime configuration:
iptables-save
1 Like
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.
2 Likes
This makes clear sense!
Thank you both for your help!
I will do some more testing...
1 Like