Wide Area Network

Table of contents
  1. Virtual Private Network Subnet
  2. Client Configurations
  3. Unique route for client
  4. Subnets at the OpenVPN Server
  5. Subnets at the OpenVPN Client

When using OpenVPN to secure traffic between two sites (where each site is sharing subnets.)

The following discusses the configurations on the Central Host server.

Our network scenario is:

Wide Area Network Diagram


OpenVPN Virtual Private Network Subnet:
Paths: Remote Client Configs: /etc/openvpn/ccd
Client Canonical Name Remote1 - Site #1
Remote2 - Site #2
Private IP subnets to share - Central - Remote Site #1 -

The standard OpenVPN Server configuration will be.

File: /etc/openvpn/server.conf

push "route"
client-config-dir /etc/openvpn/ccd
Line # Configuration Description
00 server Virtual Private Network Subnet. The Server takes the first host (i.e. and distributes the rest to client connections.
01 push "route" Subnets at the OpenVPN Server
02 route Subnets at the OpenVPN Client
03 client-config-dir /etc/openvpn/ccd Client Configurations. Path to a directory containing client specific configurations.

00. Virtual Private Network Subnet.

Wide Area Network - Virtual Network


OpenVPN, in server mode, will create a ‘virtual’ subnet from where hosts are allocated IP Addresses.

The Server takes the 1st network-host IP ( for itself, the rest are available for clients. Each client will be able to reach the server on

01. Subnets at the OpenVPN Server

We need to tell connecting clients, the subnets we wish for them to send to the OpenVPN Server host.

Use the __push “route ip subnet” __ config to tell connecting clients the subnets that need to be routed to the OpenVPN server.

push "route"

In our above example, we are telling connecting clients that the subnet is to be routed through to the OpenVPN Server host.

02. Subnets at the OpenVPN Client

We need to tell the OpenVPN Server host, to route traffic for subnets at the OpenVPN Client.

Use the ‘route’ configuration to tell our OpenVPN to tell the host kernel the subnets on the otherside of the OpenVPN tunnel.

route is at Remote Site #1, on the otherside of the OpenVPN tunnel, so route through the tunnel.

03. Client Configurations

To specify the directory path for Client Custom Configurations, use the client-config-dir directive as in the below

client-config-dir /etc/openvpn/ccd

Inside the specified path, configurations are simple TEXT files with client connections matched to the filename using the SSL Certificate “Common Name” CCN.

When a server/gateway client connects to the OpenVPN server, 
the daemon will check this directory for a file which matches the 
_common name_ of the connecting client. If a matching file is found, 
it will be read and processed for additional configuration file directives
to be applied to the named client.

Remote #1 Configuration

We’ve told the OpenVPN Server host to route traffic for client-side subnets into the OpenVPN tunnel, but if we have not specified for the VPN, which of the connecting clients should the traffic be routed.

Two things are required to complete the routing requirements of our traffic.

Wide Area Network - Virtual Network with CCD

File: /etc/openvpn/ccd/Remote1

Line # Configuration Description
00 ifconfig-push Specify a pre-determined IP address for the client
01 iroute Route the client-side subnet to the Client IP address
Specify a pre-determined IP address for the client

We want to specify the IP Address for the connecting client, because I find that routing is simpler this way.


Through the tunnel interface, ifconfig-push configures at the client an IP address for the tunnel interface that is routed to in the Private Network.

ifconfig-push local remote-netmask

Push virtual IP endpoints for client tunnel, overriding the ifconfig-pool
dynamic allocation. 

The parameters local and remote-netmask are set according to the
_ifconfig_ directive which you want to execute on the client machine
to configure the remote end of the tunnel. Note that the parameters
local and remote-netmask are from the perspective of the client, not 
the server. They may be DNS names rather than IP addresses, in which
case they will be resolved on the server at the time of client connection.

This option must be associated with a specific client instance, which means
that it must be specified either in a client instance config file using 
client-config-dir or dynamically generated using a client-connect script.

Remember also to include a _route_ directive in the main OpenVPN config
file which encloses local, so that the kernel will know to route it to the server's
TUN/TAP interface.

OpenVPN's internal client IP address selection algorithm works as follows:

1 -- Use _client-connect_ script generated file for static IP (first choice). 
2 -- Use _client-config-dir_ file for static IP (next choice). 
3 -- Use _ifconfig-pool_ allocation for dynamic IP (last choice).

More importantly, the HOWTO adds the following:

[ Configuring client-specific rules and access policies ]

Each pair of ifconfig-push addresses represent the 
virtual client and server IP endpoints. They must be taken 
from successive /30 subnets in order to be compatible with 
Windows clients and the TAP-Win32 driver. Specifically, 
the last octet in the IP address of each endpoint pair must 
be taken from this set
[ 1, 2] [ 5, 6] [ 9, 10] [ 13, 14] [ 17, 18]
[ 21, 22] [ 25, 26] [ 29, 30] [ 33, 34] [ 37, 38]
[ 41, 42] [ 45, 46] [ 49, 50] [ 53, 54] [ 57, 58]
[ 61, 62] [ 65, 66] [ 69, 70] [ 73, 74] [ 77, 78]
[ 81, 82] [ 85, 86] [ 89, 90] [ 93, 94] [ 97, 98]
[101,102] [105,106] [109,110] [113,114] [117,118]
[121,122] [125,126] [129,130] [133,134] [137,138]
[141,142] [145,146] [149,150] [153,154] [157,158]
[161,162] [165,166] [169,170] [173,174] [177,178]
[181,182] [185,186] [189,190] [193,194] [197,198]
[201,202] [205,206] [209,210] [213,214] [217,218]
[221,222] [225,226] [229,230] [233,234] [237,238]
[241,242] [245,246] [249,250] [253,254]
Route the client-side subnet to the Client IP address

With the IP Address specified for the client, it simplifies setting the routing for subnets at the client.


iroute tells OpenVPN that traffic INSIDE the Virtual Network should route (the iroute range) to this client. (@

iroute network [netmask]

Generate an internal route to a specific client. The netmask parameter,
if omitted, defaults to 

This directive can be used to route a fixed subnet from the server to a
particular client, regardless of where the client is connecting from. 
Remember that you must also add the route to the system routing table 
as well (such as by using the route directive). The reason why two
routes are needed is that the route directive routes the packet from the
kernel to OpenVPN. Once in OpenVPN, the iroute directive routes to 
the specific client.

This option must be specified either in a client instance config file using 
client-config-dir or dynamically generated using a client-connect script.

The iroute directive also has an important interaction with push "route ...".
iroute essentially defines a subnet which is owned by a particular client 
(we will call this client A). If you would like other clients to be able to reach
A's subnet, you can use push "route ..." together with client-to-client to
effect this. In order for all clients to see A's subnet, OpenVPN must push
this route to all clients EXCEPT for A, since the subnet is already owned 
by A. OpenVPN accomplishes this by not not pushing a route to a client
if it matches one of the client's iroutes.