User Tools

Site Tools


inbox:howto:vpn.server.openvpn.gateway

Using a VPN-gateway decoupled from the gateway of the network

Overview

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.

Procedure

Outline of the procedure

  • 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 VPN-connections as VPN-server and VPN-client.
  • VPN-server will require firewall rules (redirects) on the OpenWrt gateway.

crucial point, routing

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 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 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.

This website uses cookies. By using the website, you agree with storing cookies on your computer. Also you acknowledge that you have read and understand our Privacy Policy. If you do not agree leave the website.More information about cookies
inbox/howto/vpn.server.openvpn.gateway.txt · Last modified: 2019/03/23 20:08 by vgaetera