OpenWrt is a great system, but has also limitations. Recently the trend for production services within SOHO (small office, home office) scenarios is to get their own platform where to run. The same could be done with network services that normally are stacked on a single OpenWrt system.
In this case we analyze the possibility of decoupling a VPN-server/client from the gateway.
Assuming that with the VPN-tunnels networks using segment in the private address list are used, then the gateway should provide proper routing to the VPN-gateway and viceversa.
Supposing that the local lan network is
192.168.11.x, the gateway is
192.168.10.1 and the VPN-gateway is
There is a VPN-tunnel on the VPN-gateway that connects this local network with a remote network,
Workstations are in the range
Now suppose systems from the remote network wants to reach workstations in the local network. This means (assuming that the VPN-client and servers are setup properly) that their packets will reach the VPN-gateway. In the case the VPN-gateway has a VPN-server, then on the gateway there should be a rule, in the firewall, like:
config redirect option target 'DNAT' option src 'wan' option dest 'lan' option proto 'tcpudp' option src_dport '1194' option dest_ip '192.168.10.4'
Their packets then could flow without problems directly from the VPN-gateway that is in the same address segment of the workstation. The problem is that when the workstation replies, it does not know how to reach the network 192.168.20.x if not asking the gateway.
So the reply reach the gateway that has to route it properly, to the VPN-gateway (only the VPN-gateway, in a simple setup, knows how to reach the remote network segment, using the VPN-tunnel).
A way to redirect all the traffic that could go to segments of the private addresses class is to put routes to all those segments towards the VPN-server with a lower priority. Therefore if the network is directly known to the gateway, a different route will be chosen, otherwise the lower priority route will be used.
This means, on the gateway, to have the following routes in the network config:
config route list comment 'routing all possible private addresses to VPN-gateway' list comment 'with different metric' option interface lan option target 10.0.0.0 option netmask 255.0.0.0 option gateway 192.168.10.4 option metric 100 config route list comment 'routing all possible private addresses to VPN-gateway' list comment 'with different metric' option interface lan option target 172.16.0.0 option netmask 255.240.0.0 option gateway 192.168.10.4 option metric 100 config route list comment 'routing all possible private addresses to VPN-gateway' list comment 'with different metric' option interface lan option target 192.168.0.0 option netmask 255.255.0.0 option gateway 192.168.10.4 option metric 100
Therefore the gateway, instead of sending the reply of the workstation to the default route (internet:
0.0.0.0/0 ), it will send it to the VPN-gateway, that then will know how to properly route the reply to the remote network.
Instead, if a system from
192.168.20.x wants to reach a system in
192.168.11.x, its request will array on the VPN-gateway that then will use the local defaul gateway,
192.168.10.1, to route the request since the VPN-gateway knows only the
192.168.10.x network directly.
The gateway knows every network so it can route the request to the
Now systems in the
192.168.11.x behave like the workstations before, and will use the gateway to route their reply, the reply will be routed from the gateway to the VPN-gateway as seen before, and the communication will be properly established.