Configuring Protected Point2Point for OpenVPN Access Server

DISCLAIMER: Please note that the information presented in this article is for ADVANCED USERS ONLY! Misconfiguration of the settings below can create a magnitude of network problems, including rendering your network unusable. Please take this into consideration before performing the steps below.


Normally speaking, to achieve bidirectional connectivity between the target computers and the computers on the VPN network without manual port forwarding, OpenVPN Access Server requires that you operate under the OSI Layer 2 mode or the OSI Layer 3 mode with Advanced Routing. However, configuration under these modes present some challenges as it requires that certain criteria to be met before completing such configuration. As such, protected point-to-point provides a third method for which the remote endpoints can communicate with your VPN computers bidirectionally.
Protected Point to Point may be suitable for you if:

  • Your system does not meet the requirements for Layer 2 Bridging. (e.g. If you are running Hyper-V, or a VPS environment that does not support Ethernet Bridging)
  • You want to run Layer 3 with Advanced Routing, but you do not have permission to add static routes on your router. (Ordinarily a static route must be added on the remote router to point the VPN subnet/addresses to the AS IP address for processing)
  • You want to distribute public IP addresses to your VPN clients that would be fully addressable on the Internet, but at the same time you want to protect your network from unauthorized spoofing attacks, or aka. "IP snatching".


In this mode, broadcast and multicast traffic on the remote network are not redirected towards your VPN clients. Although this provides some isolation and security between the connected VPN clients and your remote network, this mode will not suffice if the application(s) you are running requires support for broadcast and/or multicast traffic (e.g. Network/Peer/Device Discovery - most applications do not require broadcast/multicast traffic support). If you plan to run such applications, you must run Access Server in the Layer 2 Operating Mode.
This mode will also add a default gateway to your routing table disregarding the Should client Internet traffic be routed through the VPN? setting in VPN Settings. If you do not want traffic to be routed over your VPN by default, you will need to change the gateway route metric using the route-metric directive.


To successfully implement protected Point-to-Point for your AS system, the following requirements should be met:

  • You must be able to subdivide your current subnet into another canonical subnet, and this canonical subnet must contain at least 5 IP addresses (see exception if you are distributing public IPs below).
  • The subdivided subnet MUST NOT be used by ANY remote computers on the remote network. These IP addresses must be solely reserved for the VPN clients at all times, whether or not the IP itself is actually being used by a VPN client (see exception if you are distributing public IPs below).
  • You must be running a compatible kernel that supports the proxy_arp sysctl. (Most modern kernels have this built-in).
  • VERY IMPORTANT: To prevent potential network problems, you should only attempt this mode if your AS server has one physical network adapter.
  • You must have root access (via SSH or the console) to the computer Access Server is on, and you must have rights to change AS settings in the admin UI.

Preparation & Planning:

For this setup to successfully work, you must first figure out how to properly divide your current subnet. For example, if your current remote subnet is ( -, a simple division would be to divide this subnet in half.
Such division will turn one /24 subnet into two /25 subnets, and in this case, FROM ( - INTO ( - AND ( -
You can then reserve the second half of your subnet for your VPN clients, in which for the purpose of this setup you would use for your subnet selection (Just remember you cannot have any other remote computers residing in this subnet, otherwise connectivity issues will arise).

If you need help on calculating the proper IP addresses and subnet mask, there is a tool available to assist you with this calculation: Subnet Mask Calculator.

For distributing a small block of public IP addresses to your VPN clients:

Now, you might ask: "What IP address and subnet mask should I use if I purchased a small block of IP addresses from my provider and I want to distribute these IP addresses to my clients?"
If you have only purchased a small block of IP addresses from your provider (e.g. 5 IP addresses), then the above scenario may not work very well for you because it will be very difficult to subdivide such small subnets into even smaller subnets. That being said, you can use the same canonical subnet as those of your allocated block range IF your VPN clients do not need access to any network resources on that local subnet.

To clarify things a little, consider the following hypothetical example:
Let say that your provider assigned your AS a public IP of with a subnet mask of (/24). You then went ahead and purchased a block of IPs of 5 IPs which the provider assigned to your server.

Looking at your server, you see that the provider gave you five additional IPs from - with the same subnet mask. From this configuration, you should realize that this block resides in the canonical subnet of
Note: If you do not know how to derive the canonical subnet from an existing IP address ( and subnet mask (, or in CIDR form /24), please visit the Subnet Calculator link above and punch in and netmask (or 24). The appropriate canonical subnet will appear under the Network: section of the results. The first and last addresses of the canonical subnet will be shown under Network: and Broadcast:, respectively.

If your clients have no intention whatsoever in accessing any resources inside ( - over the VPN, then for the purpose of setting this up, you may use the same canonical subnet in which the additional block is in (in this case, Your client will lose access to these IPs while connected to your VPN, so please take into consideration of this fact when setting it up in this way. You will not want to do this if your subnet mask is large (ex., or in CIDR form /16), because doing so will very likely disable access to common services on the Internet inadvertently.

If you would like to limit this loss, you may alternatively choose to construct a new canonical subnet that includes these five IPs in which your server is assigned with. While you will still lose access to some adjacent IPs, the loss of access is much more limited compared to if you were using the complete subnet as described above.

To begin, take the allocated block from above ( - and pad two IPs to the left and right of it, so it becomes ( -
Using the Subnet Calculator, enter the first IP of the modified range ( with the netmask of 32. Copy the 0s and 1s from the resulting Address: field (00001100.00100010.00111000.11000110) into a scratch area such as Notepad.
Repeat the following steps for the end IP ( - 00001100.00100010.00111000.11001110).

Now on the scratch area, compare the number of 0s and 1s that line up from the left, and stop counting when you hit a mismatch:
00001100.00100010.00111000.11000110 -
00001100.00100010.00111000.11001110 -
Each block separated by a dot represents eight zeros, and since 3 blocks + 4 numbers line up, a total of ( 3 x 8 ) + 4 = 28 numbers matched between these two IPs.
This number is your CIDR netmask. Now, go back to the subnet calculator and enter the start IP as the IP address, but this time with a subnet mask of 28.
You should see ( - as your canonical network. This is the network you would be using to setup protected point-to-point in the next steps.

By using this method, you have limited your connectivity loss to 11 adjacent IPs ( - and ( -, rather than 249 adjacent IPs if you were to use the aforementioned full subnet method ( - and ( -

This method will not work, however, if you have an allocation block that:

  • Has a start boundary of .2 or less (e.g. -, or:
  • Has a end boundary of .253 or more (e.g. -, or:
  • Traverses into another IP block (e.g. -

For the first scenario, you will not be able to left pad your allocation block. That being said, you can still right pad your allocation block. From the method mentioned above, you should come up with a canonical subnet of ( - Under this case, you will lose the first IP of your allocation block since the first usable IP is reserved for AS use for routing purposes.

For the second scenario, you will not be able to right pad your allocation block. That being said, you can still left pad your allocation block. From the method mentioned above, you should come up witha canonical subnet of ( - Under this case, you will lose the last IP of your allocation block since the last usable IP is reserved for AS use for DHCP responses.

For the last scenario, you have two options:

  • You can left pad your first section until the last IP ( - and then right pad your section from the start of the next section ( -, resulting two separate canonical subnets for your VPN client: ( - and ( -
  • You can increase your subnet mask to a /23, which covers both 56 and 57 sections ( - This, however, means that the number of adjacent lost IPs will also increase drastically.

Configuring Access Server:

To begin configuring your Access Server for Protected Point-to-Point, log on to your server via SSH or the console.
1. Identify the name of the network adapter which is currently connected to your network by issuing the ifconfig command. (e.g. eth0, venet0, etc.)
2. Once the adapter name is identified, open up a text editor and open /etc/sysctl.conf.
3. Add the following to the beginning of the file: net.ipv4.conf.'adapter name here'.proxy_arp = 1. If your adapter name was eth0, prepend the line net.ipv4.conf.eth0.proxy_arp = 1 to the file.
4. Save the file, and exit the text editor.
5. Execute the command: sysctl -p ; The command should return with net.ipv4.conf.eth0.proxy_arp = 1 (or with whatever your adapter name was).

6. Logon to the Admin UI. Click Group Permissions, and create a new Group by entering a custom name in the text box, then click Show to show all the configurable settings for the group.
7. Enter the subnet(s) you have chosen in the previous step of this article into the Subnets assigned to this group (optional): box (e.g. If you want Access Server to dynamically allocate IPs to your clients, enter these IPs in the "Dynamic subnet ranges for this group (optional):" box. You will want to make sure that you do not accidentally list your AS external IP or the remote gateway IP in this range if you do this.
8. Click Save Settings.

9. Click VPN Mode in the navigation bar, make sure the mode is set to Layer 3 (routing/NAT). Update if necessary.

10. Click VPN Settings in the navigation bar, under Routing: Should VPN clients have access to private subnets (non-public networks on the server side)?, select Yes, using routing (advanced). VERY IMPORTANT: Change both Dynamic & Static networks to a unused private range (e.g. and on the local network.
11. Enter in the Specify the private subnets to which all clients should be given access (as 'network/netmask_bits', one per line): box and make sure the Allow access from these private subnets to all VPN client IP addresses and subnets is checked.
12. If you want to ensure that all Internet traffic flows through the VPN, select Yes under Should client Internet traffic be routed through the VPN?. If you do not want Internet traffic to go through the VPN, select No here, Save Settings, and then go to the Advanced VPN section in the AS settings, and add push "route-metric 500" in the Server Config Directives box.

13. Click User Permissions, and then Show for the user of interest. Under Select IP Addressing :, select Use Static, and provide an IP address that is inside your canonical subnet. Enroll your user in the group you have created earlier by selecting it from the dropdown list.
14. Click Save Settings.
15. Click Update Running Server.

16. Configuration for Protected Point-to-Point is now complete!

OPTIONAL: Configure Isolation Between VPN Clients

If you would like to isolate your VPN clients so they cannot talk to each other, do the following (note that the Should clients be able to communicate with each other on the VPN IP Network? option in Advanced VPN will not have any effect when this mode is enabled):
1. Execute the following command: /usr/local/openvpn_as/scripts/confdba -mk iptables.append -v true
2. Execute the following command: /usr/local/openvpn_as/scripts/sacli start
3. Execute the following command: iptables -I FORWARD -m mark --mark 0x2000000 -d 'canonical subnet here' -j DROP (e.g. iptables -I FORWARD -m mark --mark 0x2000000 -d -j DROP)
You may want to add this rule in to a post-up start rule in your interfaces file so this command will survive a reboot.