Open VPN Access Server uses NAT (Network Address Translation) to “ease” routing VPN user traffic to the rest of a remote network. This isn’t always a desirable configuration.
If you want to disable NAT globally, you can do so by logging into the shell as a root user on your OpenVPN Access Server and doing the following:
./sacli --key vpn.server.nat --value false ConfigPut
This globally disables NAT on the box and you can then use routing tables on your network to manage traffic flow. This is handy when you already have an established network with a device (or two) that are handling routing for you and will definitely fit some use cases.
For clarity’s sake I will go ahead and state the following: This is for OpenVPN ACCESS SERVER, not for the open-source/free community edition. They are very different beasts so take note of which you are using.
I am just archiving this link for myself (and anyone else that needs this information) as well as the pertinent information therein.
Basically if you run multiple OpenVPN servers in your environment you probably need your OpenVPN Connect Client to be able to handle multiple profiles. This isn’t enabled out of the box for the client software. A little googling though and I came across this article:
Heartbleed was a major vulnerability in the SSL protocol used by many many sites and services. Folks have been scrambling to patch it up quickly since it was announced a few days prior.
If you are in the process of doing just that for yourself or your organization, you might be so busy fixing websites and webservers that you forget about other services that also make use of the OpenSSL protocol.
One such service, OpenVPN. Particularly “Access Server” as it has a client-facing Web front-end. Luckily, there is already a new version of access server released and updating your existing servers is quite simple on most Linux distributions.
Most UTM (unified threat management) Firewall devices worth their price tag include a VPN server as part of the mix. In my experience, a UTM is an excellent choice for a small office and/or most smaller enterprises as several of the higher-end devices scale quite far. For a larger, corporate network though, while a UTM (or two or three) might be part of the security mix, larger dedicated components often make more sense.
That being said, if you have a UTM, and it includes a VPN solution, you may be considering taking advantage of this for remote network access. While I wouldn’t necessarily advise against doing this, before going to far down that road I would tell you to look into deploying OpenVPN Access Server instead with Google Authenticator. Here is why…
Google Authenticator, and (all?) other rotating-pin multi-factor authentication systems, rely on the clock on the token device (in this case your smart-phone or tablet) and the authenticating system (in this case the OpenVPN server). If the clocks are different by more than a few seconds or so, it will break your authentication. (more…)