No flaws found in OpenVPN software. Our response to the CVE-2019-14899 vulnerability report.

Reach OpenVPN clients directly from a private network

Request More Information

By submitting this form, you agree to our Terms of Use and acknowledge our Privacy Statement


When you use the settings in the Access Server to give VPN clients access to resources near the Access Server, like for example a file server or web server in the same private network that the OpenVPN Access Server is on, then access is granted usually with the NAT mechanism when you first start out. With NAT, or Network Address Translation, the source address of packets of information from the VPN client in the VPN client subnet, is translated to the local private IP address of the Access Server, before being sent onto the private network and to the target system. The purpose of this is to make the traffic look like it is local traffic within the private subnet, and to avoid introducing the VPN client subnet IP addresses into the private network behind the Access Server.

By using NAT in this way, no additional routes need to be setup, and the target system can simply respond back within the local network without having to involve a gateway system, since it’s all just local traffic. So this makes things easier and makes adding static routes in the gateway or in the operating system unnecessary. Unfortunately it also means that there is no direct path from the private network behind the Access Server, to the VPN client subnet itself, because there’s no information known about how to get there, and the NAT solution works in only one direction (from VPN clients to private network behind Access Server). In a way this works a little like a type of firewall. The OpenVPN clients remain unreachable from your private network, but they can still access resources in your private network.

If you want direct contact then you’ll have to set things up to use routing instead. With routing, there is no address translation. That means traffic coming from a VPN client in the VPN client subnet, gets forwarded as-is on to the target private network behind the Access Server. This target network then must be made aware of where this VPN client subnet can be reached. This is done by adding either a static route in the default gateway of the target private network, or in the operating system of the particular server you are trying to reach. The static route should point to the private IP address of the OpenVPN Access Server in the private network. And traffic can then go in two directions and be initiated from either side.

VOIP protocol especially does not like NAT, and will usually work well with routing instead.

Change from NAT to routing

In the simplest setup, which Access Server starts with by default, the private network that the OpenVPN Access Server is a part of, is configured for NAT access. All VPN clients that are connected will be given access to the private network behind the Access Server, using the NAT method. This can be configured in the Admin UI under VPN Settings, Should VPN clients have access to private subnets, yes, using NAT. With this type of setup traffic can go from the VPN clients to the computers in the private network, and responses sent back are then translated back by the Access Server to the original VPN client that made the request. Direct access to the VPN client IP subnet is not possible.

To enable two-way traffic using routing, go to VPN Settings, Should VPN clients have access to private subnets, and set the option to yes, using routing (advanced) instead. Leave the check mark in the Allow access from these private subnets to all VPN client IP addresses and subnets checkbox. Then save settings and update running servers. That completes the configuration from the Access Server side. You may notice that if you try the connection now it may appear to fail. Appear to, because most likely the traffic now is actually making it from the VPN clients to a target in the private network just fine, but the target network may not have a clue on how to respond to traffic coming from a subnet (the VPN client subnet) that is unknown to it.

To make things work properly again now you have to look up the static route table in the default gateway system in your private network. If your VPN client subnet is for example, and your OpenVPN Access Server installation is at IP address then add this static route:

  • Network with subnet mask to go through gateway

Now traffic should find its way in both directions. From the VPN client subnet to the private network, and from the private network to the VPN client subnet. Two-way traffic is now possible in routing mode, and access can be initiated from either side.


Whenever you have trouble getting traffic to pass through with the OpenVPN Access Server, you should try to determine the exact spot where things break. To visualize this we use tools like tcpdump and ping to find the point where traffic breaks. We describe this in detail on our troubleshooting reaching systems over the VPN tunnel page.