What is DNS?
Domain Name System, or DNS, is the system on the Internet that resolves names like openvpn.net to an IP address like 123.45.67.89 on the Internet. IP addresses are the unique addresses of computer systems in networks, and the Internet is one big network. These addresses work like phone numbers. They are unique and allow communication between the different computers on the Internet. To expect humans to remember IP addresses for all the various websites they want to visit, is simply not practical. So we create DNS names like openvpn.net, google.com, facebook.com, on the Internet, and let a DNS server take care of translating names to IP addresses. It can also be used for shorter host names in an internal network to resolve a name like pc1 to a private IP address.
How do I set HTTP Strict Transport Security?
Refer to our support article: How do I set HTTP Strict Transport Security (HSTS) on Access Server?
What is the lockout policy on Access Server?
A lockout policy is a method of preventing people from brute-forcing the password. Brute-forcing is simply endlessly guessing passwords until you hit the right one. Obviously you don't want an internet-facing system to be susceptible to this. It's important to note that the openvpn administrative account on Access Server versions older than 2.10 is not subject to the lockout policy. Refer to Secure the openvpn administrative user account for our recommendations in improving security for this account, depending on your version of Access Server. All other accounts are subject to the lockout policy.
In short, the policy is that after five failed login attempts on a user account, that user account is blocked from signing in for 15 minutes, as of Access Server version 2.10. Access Server 2.9 and older use the default of three failed attempts. After 15 minutes, the lockout is released. You can adjust this policy to your needs. It cannot be disabled in the sense that there's an on/off switch or setting in Access Server, but you can effectively disable it by setting a ridiculously high value like one million wrong passwords before locking the user out for one second, for example. It can only be configured using the command line tools. For more details about changing the default settings, see this command line documentation page regarding the lockout policy.
How do I unlock users that are locked out now?
There is no reset command for this, so you will have to wait until the expiration timeout passes. What you can do is set the expiration timeout to 1 second, then wait 2 seconds, and then set it back to whatever the setting originally was. This effectively expires the lockout on all users on your server all at once within a second or two, and lets you log on again immediately. To do this run this set of commands shown below. Afterwards you should reconfigure your lockout policy expiration setting if it was different from the default 15 minutes lockout time. Note: all the command line tools assume you are in the /usr/local/openvpn_as/scripts/ directory and have root privileges.
Reset all lockout policy lockouts now:
./sacli --key "vpn.server.lockout_policy.reset_time" --value "1" ConfigPut ./sacli start sleep 2 ./sacli --key "vpn.server.lockout_policy.reset_time" ConfigDel ./sacli start
The lockout policy can be adjusted to match your needs. See also what is the lockout policy on Access Server for more details.
How can I set a static IP address on my Linux server?
We will only describe the process for the Ubuntu operating system, as that is the operating system that we have been using for years to distribute our HyperV, ESXi, Amazon AWS, and Azure appliances on. If you have another operating system you can look online how to configure things exactly.
Since Ubuntu 18 the program netplan is now the commonly used program to set the network IP address. In the past this was set with ifupdown which used a configuration file called /etc/network/interfaces, which still applies to Ubuntu 16 and older platforms, but as mentioned, we now try to use netplan on our images.
- Instructions on how to set a static IP address on Ubuntu 16 or older
- Instructions on how to set a static IP address on Ubuntu 18 or newer
What is and how do I enable IP forwarding on Linux?
IP forwarding is the ability for an operating system to accept incoming network packets on one interface, recognize that it is not meant for the system itself, but that it should be passed on to another network, and then forwards it accordingly. This is what you need when you have for example a system setup that is sitting between two different networks and needs to pass traffic between them. On pretty much any Linux system, barring a few exceptions, this can be accomplished by editing the /etc/sysctl.conf file and adding or uncommenting a specific line. To enable IP forwarding on Ubuntu/Debian for example you can do this:
Open the file /etc/sysctl.conf in the nano text editor:
nano /etc/sysctl.conf
Uncomment or add this line:
net.ipv4.ip_forward=1
Press ctrl+x, then press y, and then press enter, to save and exit the file. Next run this command:
sysctl -p
The alterations you've made to the sysctl.conf file should now have taken effect and IP forwarding should now be enabled permanently on this system. Please note that OpenVPN Access Server always ensures this is enabled by default, so no need to implement this on the OpenVPN Access Server installation itself.
How to route to an additional separate gateway and subnet?
In some of the more complex setups there are additional gateways with behind them additional subnets. If the OpenVPN Access Server itself can ping that gateway but cannot reach the subnet behind it, then the most likely solution here is to add in the routing table of the operating system where the Access Server is installed a route that directs traffic intended for the target subnet through the additional gateway. If traffic is then possible between the OpenVPN Access Server and the target subnet, then VPN clients should also be able to reach that target network as long as you give them access using the fields in user and group permissions and use the NAT method to give VPN clients access. If you use routing then it may not work because the VPN client subnet may be unknown to the target subnet. If you want to use routing then you should also implement a route back to the VPN client subnet using the OpenVPN Access Server's IP address in your network as the gateway address. It will function as a gateway to the VPN client subnet automatically.
To give VPN clients access to the additional subnets you can simply specify in the fields where you give users and groups access to subnets on the Access Server the additional subnets you want them to be able to reach. The traffic will then follow a path that goes from OpenVPN client to OpenVPN Access Server, and in the routing table there it will find the correct gateway and send the traffic there. That gateway then delivers it to the correct subnet. Responses generated there should then find their way back via static routes or routing tables to the IP address of the OpenVPN Access Server, and that will then send it to the OpenVPN client.
As usual, routing must be symmetrical, so it must function in both directions equally.
Why does OpenVPN use UDP and TCP?
The OpenVPN protocol itself functions best over just the UDP protocol. And by default the connection profiles that you can download from the Access Server are preprogrammed to always first try UDP, and if that fails, then try TCP. Unfortunately, on some more restrictive networks, all traffic except very commonly used ports are simply blocked. For example on a public network it can be quite normal to see that only traffic for protocols such as HTTP, FTP, SMTP, POP3, and IMAP, are allowed, with usually some additional ports for SSL secured versions of those protocols, like HTTPS. Those protocols are almost all TCP-only and not UDP. On such networks it's useful to also support TCP connections, even though this is less ideal due to the possibility of the TCP Meltdown phenomenon. But given the choices between something that works reasonably well or not at all, we've chosen to be practical and also support TCP. By default we choose the port TCP 443 which is the same port as HTTPS traffic, which is usually allowed even on restrictive networks.
What is TCP Meltdown?
TCP stands for Transmission Control Protocol. Basically a means of sending traffic over the Internet with some built-in measures to ensure that traffic can get to its destination. If anything goes wrong during transmission, the protocol has some means to try to find a solution (send the packet of information again or try an alternative route or such). TCP Meltdown occurs when you stack one transmission protocol on top of another, like what happens when an OpenVPN TCP tunnel is transporting TCP traffic inside it. The underlying layer may detect a problem and attempt to compensate, and the layer above it then overcompensates because of that, and this overcompensation causes delays and problems with the transfer of data. That's the layman's version of it that is easy to explain and understand. We therefore instead recommend that you use UDP, which has no transmission control, and on top of that send your TCP traffic as usual, so that there's only one layer of transmission control, and the problem can be avoided.
Some people mistakenly believe that TCP is the best protocol to ensure the best reliability and performance for sending traffic over the Internet. This is the exception.
If you want to learn more there's a good article here on an external website: Why TCP Over TCP Is A Bad Idea
What is the OSI Layer model?
It is an abstracted view of a computer network, like for example your local computer network at home or in the office, or on a larger scale, the Internet. There are 7 layers that describe their own specific function in the whole. The first 3 are really the important ones that Access Server works with:
- Physical, or Bit - The cables and equipment that transfer bits of data from one device to another.
- Data link, or Frame - Frames of data that reliably carry data between two devices connected by a physical medium.
- Network, or Packet - Structuring and managing a multi-node network, with addressing, routing, and traffic control.
For a full list see the Wikipedia article about the description of OSI layers.
The Access Server by default operates on Layer 3 routed mode, where it functions like a router would, for the most part. You connect to it using our OpenVPN client software, and traffic intended for specific IP addresses can be routed through the VPN tunnel. You can for example allow 192.168.70.0/24 through, but leave all the other subnets and IP addresses on the client side. Or you can redirect all Internet-directed traffic from the VPN client through the VPN tunnel and through the VPN server. The point is you have control over which traffic goes through the VPN tunnel, and which traffic doesn't.
It is also possible for Access Server to operate in Layer 2 bridging mode, where it functions like a network switch or hub would, for the most part. You connect to it using our OpenVPN client software, and your client computer becomes bridged to the network that the Access Server is on. It connects you directly, so to speak. You have little to no control over what traffic goes through the VPN tunnel then. You can either enable or disable sending Internet-directed traffic from the VPN client through the VPN tunnel but that's about all the control you have over the traffic that flows through here. It also means broadcast traffic will be able to pass unimpeded through the link. For some older legacy software this may be necessary, but it is also quite ugly in the sense that if you have for example a 100 VPN clients connected, and 1 VPN client sends 1 megabyte of broadcast traffic through the VPN tunnel, then that gets re-broadcast by the Access Server to the other 99 VPN clients. That's a lot of data at once. It is for these reasons that we very strongly recommend to stick to the default Layer 3 mode. If however you are determined and knowledgeable enough to use Layer 2 bridging mode then you can find the instructions on how to switch to Layer 2 bridging mode here.
Why does Access Server have multiple network interfaces?
This is a side-effect of the fact that the OpenVPN 2 codebase is single-thread. That means it runs as a process on one CPU core and can't make use of multiple CPU cores at once. To get around the obvious performance limitation this creates on a server with multiple CPU cores, we spawn multiple OpenVPN daemons on the Access Server. We spawn 1 TCP and 1 UDP daemon per CPU core by default. An internal simple load-balancing system using iptables connects VPN tunnel connection requests coming in to the least loaded OpenVPN daemon.
Each OpenVPN daemon needs it own network interface to communicate with the operating system. The Access Server makes sure people connected to 2 different OpenVPN daemons can still contact each other if that is necessary. All the communication simply passes through the operating system and hits the routing table which determines which interface traffic should go to. So this doesn't cause a situation where clients are separated from each other when one is connected to one OpenVPN daemon, and the other to another OpenVPN daemon.
The interfaces looks like as0t0, as0t1, as0t2, as0t3, and so on, and each get a portion of the subnet defined in the settings in the Access Server.
Why is the subnet smaller than I specified?
This is related to why Access Server has multiple network interfaces. Each OpenVPN daemon launched needs it own subnet. So if you have 4 OpenVPN daemons running, each one gets a quarter of the subnet.
Can I run Access Server on a Raspberry Pi?
Yes. Refer to this FAQ: Can I run Access Server on a Raspberry Pi?
For how-to steps, refer to Install OpenVPN Access Server on Raspberry Pi.
How can I reach the VPN clients from my network?
Sometimes people want to be able to access the VPN clients directly from the network behind the Access Server. So if for example you have your Access Server installed in your company network, and you have the need to connect directly to a VPN client that is connected from outside to your OpenVPN Access Server, from your company network, then this is possible. But by default a lot of setups use the NAT mechanism, which lets traffic flow from VPN clients to the private networks behind the Access Server, but not the other way around. To lift this restriction you must use routing. And when you use routing, the private network in your company network must then be made aware of where the VPN client subnet is, where it can be reached. It needs to know the gateway system that can lead to the VPN client subnet. And that gateway address then is the IP address of your local Access Server installation in your company network.
Check the reach OpenVPN clients directly from a private network page for more information.
What are SSL web certificates, how do they work?
We're not going into the technical details of how the encryption works, as that would become a rather long winded mathematical explanation, but we are going to explain a bit about how SSL certificates play a role in securing Internet traffic. SSL stands for Secure Sockets Layer and is sort of an add-on to an existing system. For example, HTTP traffic is the type of traffic that web browsers use to transfer information from a web server, like the Access Server's admin UI, to your computer, in the web browser. HTTP by itself is completely unsecured. Anyone intercepting the traffic between your web browser and a web server that uses the HTTP protocol, can see all the pages and texts and information flowing over the network, and can read along with what you're seeing in your web browser. Obviously that is terribly insecure when you're visiting a website of a bank or other financial institute. Therefore a security layer is added call SSL. If you apply this to HTTP it becomes HTTPS instead - a secure version of HTTP. With SSL an encryption layer is set up and any traffic flowing over that connection is unreadable to outsiders. This is done using a very clever system using prime numbers and mathematical calculations that make it impossible for anyone trying to intercept the traffic to see what's going through the encryption connection. Over this encrypted connection, normal HTTP is transferred. But this is only visible and legible to the web server itself, and your web browser. Anyone in between will just see encrypted information, useless to them.
But encryption alone is not the only purpose. Another important purpose is establishing trust. Can you trust that the server you are connecting to, is actually the server that you think it is? For example if you are visiting your bank's website, how can you be sure that this is actually the bank's website, and not some other site that cleverly looks a lot like it, but isn't actually your bank's website at all? That's one of the main purposes of SSL certificates - to determine identity of the server and holder of the private key and public key. SSL certificates consist of 2 major components: a private key, and a public key. The private key is generated by the bank itself, and stays with the bank. Nobody else ever gets to see that private key. It is a series of random numbers and letters that has been stored on the web server of the bank and doesn't ever get shown to anyone else. That is the secret key that nobody else but the bank must know. With this private key, the system administrator of the web server uses a tool like OpenSSL to create a CSR, or Certificate Signing Request. This is a standardized form with a bunch of questions like, what is the address of your website (common name), what are your contact details, where are you located, and so on. Once all these questions are answered a file is generated that is connected to the private key cryptographically, but does not contain the private key itself. The next step is sending this to a certificate authority.
A certificate authority is a company or organization that makes it its business to confirm identity of the owner of a website, and when it has validated this, to take your CSR and sign a new public certificate with their keys. Their keys are special because they are trusted by a root authority. And root authorities are automatically trusted by your web browser or other SSL capable programs. There's a list in your web browser of known major root certificate authorities and their public keys which are automatically considered trustworthy. Any certificates they sign are trusted as well. Certificates work with a hierarchy: an SSL certificate for your website signed by a certificate authority contains in it information that identifies the certificate that stands above it - in this case the certificate authority that signed your key. And their key also contains information that identifies the certificates above it - all the way up to the root certificate authority key. So it forms a chain from the public key (certificate) they create for your website, all the way to a trusted root authority. Your web browser or other SSL capable program automatically tries to follow this chain and if it ends up at a root authority certificate that is trusted by your computer, then the private key you get is also automatically trusted.
This signed key is a public key that is cryptographically tied to your private key, but does not contain the private key itself. They are inextricably linked. The public key, as the name indicates, is installed on the web server and anyone that visits gets a copy of it. It's like showing your passport to whomever wants to see it to confirm your identity. But only a trusted authority can issue a passport, and only they know things about you like where you were born, where your live, etcetera, and that you are truly the holder of this passport. Like on a passport, the country and authority that issued it will be mentioned on it. In SSL certificate terms this is the certificate authority that issued you your certificate. Anyone seeing the SSL certificate can check with the authority above it to see if it's a real certificate.
A neat property of a public-private key pair is that they are linked. If you as a visitor receive the public key, and check it with the certificate authorities above it to see if it's a real certificate that is trusted by a root authority, then you can do the next test: is the web server showing you this public key also the holder of its linked private key? If not then they're just faking it. So this needs to be tested. Modern passports can have biometric data integrated into it, like fingerprints and such. Only the real holder of the passport can give their biometric data in a fingerprint test and actually have it match to what is known on the passport. Likewise, anything encrypted using the public key can only be decrypted by the holder of the private key that belongs to this specific public-private key pair. So by simply sending information encrypted with the public key and receiving a sensible response you can be sure that the web server you're talking to is really the correct web server. After all, only the private key that was used to create the original Certificate Signing Request, which was then approved and signed by a certificate authority and resulted in a public key, can be used to decrypt data encrypted with the linked public key.
So that's your proof of identity and method of establishing trust. That's, simplified, how SSL certificates play a role in securing Internet traffic and making sure you are connected to the correct web server.