Wide Area Network
Table of contents
- Virtual Private Network Subnet
- Client Configurations
- Unique route for client
- Subnets at the OpenVPN Server
- 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:
- Central Office has a server subnet we want to share with remote sites
- Remote Site #1 has a subnet we want to share with Central Office
Configuration:
| OpenVPN Virtual Private Network Subnet: | 172.16.1.0/24 |
| Paths: | Remote Client Configs: /etc/openvpn/ccd |
| Client Canonical Name | Remote1 - Site #1 Remote2 - Site #2 |
| Private IP subnets to share | - Central 10.0.1.0/24 - Remote Site #1 - 192.168.45.0/24 |
The standard OpenVPN Server configuration will be.
File: /etc/openvpn/server.conf
server 172.16.1.0 255.255.255.0 push "route 10.0.1.0 255.255.255.0" route 192.168.45.0 255.255.255.0 client-config-dir /etc/openvpn/ccd
| Line # | Configuration | Description |
|---|---|---|
| 00 | server 172.16.1.0 255.255.255.0 | Virtual Private Network Subnet.
|
00. Virtual Private Network Subnet.
server 172.16.1.0 255.255.255.0
OpenVPN, in server mode, will create a ‘virtual’ subnet from where hosts are allocated IP Addresses.
The Server takes the 1st network-host IP (172.16.1.1) for itself, the rest are available for clients. Each client will be able to reach the server on 172.16.1.1.
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 10.0.1.0 255.255.255.0"
In our above example, we are telling connecting clients that the subnet 10.0.1.0/24 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 192.168.45.0 255.255.255.0
192.168.45.0/24 is at Remote Site #1, on the otherside of the OpenVPN tunnel, so route 192.168.45.0 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.
- Specify a pre-determined IP address for the client
- Route the client-side subnet to the above IP address
File: /etc/openvpn/ccd/Remote1
ifconfig-push 172.16.1.5 172.16.1.6 iroute 192.168.45.0 255.255.255.0
| Line # | Configuration | Description |
|---|---|---|
| 00 | ifconfig-push 172.16.1.5 172.16.1.6 | Specify a pre-determined IP address for the client |
| 01 | iroute 192.168.45.0 255.255.255.0 | 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.
ifconfig-push 172.16.1.5 172.16.1.6
Through the tunnel interface, ifconfig-push configures at the client an IP address 172.16.1.5. for the tunnel interface that is routed to 172.16.1.6 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 192.168.45.0 255.255.255.0
iroute tells OpenVPN that traffic INSIDE the Virtual Network should route (the iroute range) 192.168.45.0/24 to this client. (@ 172.16.1.5)
iroute network [netmask] Generate an internal route to a specific client. The netmask parameter, if omitted, defaults to 255.255.255.255. 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.