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.
* An openwrt gateway is setup, and mostly will manage the following services: ddns, dhcp (limited to some logical networks, for example voip), dns (limited to small usage, the main dns is on the domain controller), firewall between logical networks, routing, wan redundancy, hardware redundancy, traffic shaping; * Another openwrt system, called vpn gateway, but with very basic configuration compared to the gateway (mostly a client of the network, reachable on ssh handling openvpn connections as vpn server and vpn client. (see also [[OpenWrt:OpenVPN]] and related pages ). The vpn server will require firewall rules (redirects) on the openwrt 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.10.x and 192.168.11.x, the gateway is 192.168.10.1 and the vpn gateway is 192.168.10.4 .
There is a vpn tunnel on the vpn gateway that connects this local network with a remote network, 192.168.20.x .
Workstations are in the range 192.168.10.100 to 192.168.10.200.
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 openvpn 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' #port where the openvpn server listen to option dest_ip '192.168.10.4' option dest_port 1194
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 choosen, 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 192.168.11.x network. 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.