Preface: I run two OpenWRT boxes: an Archer A7 as my router/AP, and an x64-based machine to handle CPU/RAM-intensive things - namely, my AdGuard Home and my VPN client. Previously, I was able to connect both OpenWRT boxes via Ethernet, and everything worked beautifully using VLANs that both boxes were aware of (specifically, routing certain WAN IP address ranges through the VPN for all LAN devices).
Current situation: Now, unfortunately, due to physical constraints, I have to use a WDS link between the boxes (see picture). In this configuration, the x64 can establish the VPN link just fine and is aware of both the .1.x and .192.x networks, but the A7 is only aware of the .1.x network and thus cannot route anything into the VPN.
Question: I assume that if I make use of firewall/routing rules on both machines I can fix this, but this is beyond my current networking capabilities. Any pointers are thus much appreciated!
The use of WDS should not change anything in the setup you are trying to achieve.
Anyway, in A7 you can add a static route. Provided that the 192.168.1.0/24 is the lan interface, use the following:
uci add network route
uci set network.@route[-1].interface='lan'
uci set network.@route[-1].target='192.168.192.0'
uci set network.@route[-1].netmask='255.255.255.0'
uci set network.@route[-1].gateway='192.168.1.254'
uci commit network
service network restart
I'm actually not sure if I was clear enough describing my issue/scenario, but this did help me find the solution, many thanks!
Based off your suggestion, I set the A7 route for my external target, let's call it 134.134.0.1/24, to the LAN interface and the x64 box 192.168.1.254 gateway. Then, on the x64, I configured a static route for 134.134.0.1/24 with the VPN interface and with the VPN gateway 192.168.192.1 (i.e., the same route that, on its own, was previously sufficient on my A7). Working now
So, turns out it's not fully solved after all - it stopped working again, with tracert from lan-connected device (192.168.1.2) showing requests that should go via VPN simply bouncing back and forth:
Tracing route to external-hostname.com [134.134.0.1]
1 1 ms 1 ms <1 ms 192.168.1.1
2 2 ms 2 ms 2 ms 192.168.1.254
3 293 ms 2 ms 2 ms 192.168.1.1
4 102 ms 3 ms 4 ms 192.168.1.254
etc.
I didn't mess with the configuration, so not sure what happened. Maybe some cache expiration? If you or someone else can find any pointers in my config for what went wrong - here they are (or at least the relevant parts):
What exactly do you want?
Do you want all traffic from all clients to go via the vpn, do you only want all traffic from some clients go via the vpn or do you only want to reach the vpn server etc.?
Sorry if I haven't been sufficiently clear on this. Traffic to external-hostname.com [134.134.0.1], originating from any device in LAN (and only this traffic), should go out via the remote VPN server (instead of the "local" cable modem).
I.e., from 192.168.1.2, this traffic should go -> 192.168.1.1 (LAN router) -> 192.168.1.254 aka 192.168.192.10 -> 192.168.192.1 (aka some dynamic WAN IP of the remote VPN server) -> 134.134.0.1
Your vpn is already connected, it might work if the vpn server supports nat hairpinning, but it is much easier to set a static route to the subnet of the vpn server
Note it should be different from the other subnets.
Furthermore you might have to snat traffic going out of the router to the vpn client otherwise traffic might be classified as invalid because it originates from the router but will not be directed back to the routetbut directly to the lan client.
Alternatively disable invalid traffic on the firewall I think there is a general invalid setting and also per interface
You have a routing loop, the ISP router is sending packets to the OpenWrt and the last is sending them back to the first.
Either the OpenWrt will have just the VPN gateway, or multiple gateways with proper metrics, or you'll create another routing table, or use pbr package.
Also some gateways you have there are invalid, so you need to fix them.
So, upon further investigation, my configuration from Post #5 is actually working, with correct forwarding between different gateways and devices as desired. The issue was that the static routing rules were lost if the vpn connection intermittently dropped, due to "Force Link" being set by default - adding option force_link '0' to the VPN interface on the x64 box resolved the issue. (solution by Malvineous here)
