The OpenVPN Server menu allows viewing and configuration of settings for Tomato's OpenVPN Server.
Two distinct VPNs can be created, each using TUN/TAP virtual interfaces. Connections are TLS-encrypted.
Start with WAN: Check this option if you need OpenVPN server to be available automatically each time the WAN interface comes up. This is suitable if OpenVPN server needs to be available 24/7.
Start Now: If the Start with WAN option is not checked, you'll need to click on the Start Now button if you want OpenVPN server to start immediately.
VPNs use virtual (software) network devices to simulate physical network adapters. OpenVPN has two main types of virtual interfaces:
TUN, (short for “network TUNnel”), simulates a network layer device. TUN operates at OSI layer 3, and carries IP datagrams. TUN is used with routing. In general, TUN is used for VPN tunnels where only IP protocol is used.
TAP, (aka “network TAP”), simulates a link layer device, operating at layer 2. TAP carries Ethernet frames. TAP is used to create a network bridge.
Since TAP allows full Ethernet frames to pass through the tunnel, TAP also provides support for non-routable protocols like IPX and AppleTalk.
Other important differences include:
Since TUN is used with routing, it can help networks to intercommunicate, while stil remaining separate. Common applications of TUN/TAP include:
Advantages and Disadvantages
Some OpenVPN setups use only one virtual interface type. Others allow users to switch between adapter types. Therefore, it's important to understand the pros and cons of each adapter type.
TUN
Advantages
Disadvantages
TAP
Advantages
Disadvantages
The Interface type(s) must be identical on server and clients. You cannot use TAP on clients and TUN on servers or vice versa.
This option becomes available if you selected the TAP Interface Type. This lets you select the VLAN to which you want to bridge the clients that connect to your OpenVPN server.
OpenVPN can run over either TCP or UDP transport protocols.
UDP OpenVPN Protocol
TCP OpenVPN Protocol
This is the port on which the OpenVPN server will be listening on the WAN interface of your router. Make sure to configure firewall / IPTables rules to allow the traffic through this port. (Default: 443).
OpenVPN allows peers to authenticate each other using a Static (pre‐shared) Key or certificates. When used in a client‐server configuration, OpenVPN allows the server to release an authentication certificate for every client, using signature and certificate authority. OpenVPN uses the OpenSSL encryption library extensively, as well as the SSLv3/TLSv1 protocol. It contains many security and control features.
Here, select the authorization mode for the OpenVPN Server
Note: Static key configurations offer the simplest setup, and are ideal for point-to-point VPNs or proof-of-concept testing.
Static Key
Advantages
Disadvantages
This dropdown will automatically appear if you have selected TLS Authorization mode.
TLS requires a multi-packet exchange before it can authenticate a peer. During the exchange period, OpenVPN allocates memory and CPU resources to the potential peer. The potential peer exposes many parts of OpenVPN and the OpenSSL library to the packets it is sending. Most successful network attacks today seek to either exploit bugs in programs (such as buffer overflow attacks) or force a program to consume so many resources that it becomes unusable. The first line of defense is always good programming code. OpenVPN was written with buffer overflow attack prevention as a top priority. However, history has shown that many of the most widely used network applications ocasionally fall to buffer overflow attacks.
As a second line of defense, OpenVPN offers this special layer of authentication on top of the TLS control channel so that every packet on the control channel is authenticated by an HMAC signature and a unique ID for replay protection. This signature will also help protect against DoS (Denial of Service) attacks. An important rule of thumb in reducing vulnerability to DoS attacks is to minimize the amount of resources a potential, but as yet unauthenticated, client is able to consume.
Enabling this setting does this by signing every TLS control channel packet with an HMAC signature, including packets which are sent before the TLS level has had a chance to authenticate the peer. The result is that packets without the correct signature can be dropped immediately upon reception, before they have a chance to consume additional system resources such as by initiating a TLS handshake.
It should be emphasized that this feature is optional and that the key file used with –tls-auth gives a peer nothing more than the power to initiate a TLS handshake. It is not used to encrypt or authenticate any tunnel data.
Use Encrypt Channel instead if you want to use the key file to not only authenticate, but also encrypt the TLS control channel.
If Auth Digest is set ton any value but None, OpenVPN will authenticate data channel packets and (if enabled) tls-auth control channel packets with HMAC using message digest algorithm alg. (The default is SHA1 ). HMAC is a commonly used message authentication algorithm (MAC) that uses a data string, a secure hash algorithm, and a key, to produce a digital signature.
The OpenVPN data channel protocol uses encrypt-then-mac (i.e. first encrypt a packet, then HMAC the resulting ciphertext), which prevents padding oracle attacks.
If an AEAD cipher mode (e.g. GCM) is chosen, the specified –auth algorithm is ignored for the data channel, and the authentication method of the AEAD cipher is used instead. Note that alg still specifies the digest used for tls-auth.
In static-key encryption mode, the HMAC key is included in the key file generated by –genkey. In TLS mode, the HMAC key is dynamically generated and shared between peers via the TLS control channel. If OpenVPN receives a packet with a bad HMAC it will drop the packet. HMAC usually adds 16 or 20 bytes per packet. Set alg=none to disable authentication.
For more information on HMAC see http://www.cs.ucsd.edu/users/mihir/papers/hmac.html
Select with this option whether you want OpenVPN to assign a custom range to the Clients or if it should use the router's DHCP to assign the IPs by clicking on the DHCP check box.
If set to something greater than 0 it will activate a watchdog poll to verify if OpenVPN is activated every n minutes. If it finds that it is not activated, it will restart the OpenVPN service.
If enabled, will instruct the clients that connect to this OpenVPN server to redirect all their internet traffic through this server (Use this server as default gateway). If disabled only LAN traffic will be directed.
The OpenVPN server can push DHCP options such as DNS and WINS server addresses to clients (some caveats to be aware of). Windows clients can accept pushed DHCP options natively, while non-Windows clients can accept them by using a client-side up script which parses the foreign_option_nenvironmental variable list. See the man page for non-Windows foreign_option_n documentation and script examples.
If enabled, clients will pull the DNS configuration from the server.
Encrypt data channel packets with cipher algorithm alg. The default is BF-CBC, an abbreviation for Blowfish in Cipher Block Chaining mode. When cipher negotiation (NCP) is allowed, OpenVPN 2.4 and newer on both client and server side will automatically upgrade to AES-256-GCM. See –ncp-ciphers and –ncp-disable for more details on NCP.
Using BF-CBC is no longer recommended, because of its 64-bit block size. This small block size allows attacks based on collisions, as demonstrated by SWEET32. See https://community.openvpn.net/openvpn/wiki/SWEET32 for details. Due to this, support for BF-CBC, DES, CAST5, IDEA and RC2 ciphers will be removed in OpenVPN 2.6.
Set this field to Disable to do not use encryption. Set this field to Enable with fallback to use the cipher set in the Legacy/fallback cipher field
This is a static field. It defines what ciphers can be negotiated during the handshaking between the Client and the Server
The available ciphers in the existing firmware are:
Please note the the above are the recommended ciphers to avoid any possible SWEET32 attack documented on the following resources:
In case the negotiation of the cipher between the client and the server fails using the available ciphers, this field defines which cipher to use as fallback
Enables a compression algorithm. LZO and LZ4 are different compression algorithms, with LZ4 generally offering the best performance with least CPU usage. For backwards compatibility with OpenVPN versions before v2.4, use “lzo” (which is identical to the older option “–comp-lzo yes”).
If the algorithm parameter is set to Disabled, compression will be turned off, but the packet framing for compression will still be enabled, allowing a different setting to be pushed later.
Compression and encryption is a tricky combination. If an attacker knows or is able to control (parts of) the plaintext of packets that contain secrets, the attacker might be able to extract the secret if compression is enabled. See e.g. the CRIME and BREACH attacks on TLS which also leverage compression to break encryption. If you are not entirely sure that the above does not apply to your traffic, you are advised to *not* enable compression.
Renegotiate data channel key after n seconds (default=3600).When using dual-factor authentication, note that this default value may cause the end user to be challenged to reauthorize once per hour.
Also, keep in mind that this option can be used on both the client and server, and whichever uses the lower value will be the one to trigger the renegotiation. A common mistake is to set this parameter to a higher value on either the client or server, while the other side of the connection is still using the default value of 3600 seconds, meaning that the renegotiation will still occur once per 3600 seconds. The solution is to increase –reneg-sec on both the client and server, or set it to 0 on one side of the connection (to disable), and to your chosen value on the other side.
Using this option, you can have full bidirectional site-to-site TLS VPNs with no Custom Configuration or init scripts.
Selecting this option displays a table where you fill in the Common Name (from when you generated the TLS certificates), subnet (optional), and netmask (optional). If you fill in the subnet and netmask of the client, your server LAN will be able to communicate with your client LAN whenever it's connected (be sure not to choose the NAT option on the client router). Without this, you're stuck with just client→server communication.
If you select the “Allow Client<→Client” option, another checkbox appears in the table that, when selected, allows other clients (or client LANs) to communicate with this client LAN. So, now you can have multiple sites all connected together with communication between any of them as desired.An “allow only these clients” option is also present. With this selected, clients that aren't in the table are not allowed to connect. If you want to allow a client that doesn't have a LAN behind it (or you don't want to allow access to it), just put it in the table and leave the subnet/netmask blank.
You can further customize the VPN server by changing its server port other than the default 1194 and change the auth digest and encryption cipher to whatever you wantAES-128-CBC and auth digest to SHA1 is sufficient encryption for maintaining a proper security when connecting to your Server. However feel free to change to whatever encryption or cipher that suits your needs.
You can specify the custom configuration to be used by OpenVPN server. Please refer to https://openvpn.net/community-resources/reference-manual-for-openvpn-2-4/ for further information about the parameters that can be used
You MUST configure the certificates if you have selected TLS as authorization mode.
Instead of a static key, you can allow the machines to negotiate an encryption key and an encryption algorithm with TLS protocol. In TLS handshake process. one machine is server and the other is client. Once the handshake is completed, the OpenVPN interaction is on peer-to-peer basis.
For TLS handshake to occur, both the server and the client must have their respective digital certificates. And also Diffie-Hellman parameters that finally lead to creation of a shared secret number need to be generated for server. You will generate our own digital certificates. As every digital certificate is issued by a CA, you will first
create a CA. The tools to create CA, certificates, and Diffie-Hellman parameters are provided by OpenVPN and are available within the deployment of FreshTomato.
The first step in building an OpenVPN 2.x configuration is to establish a PKI (public key infrastructure). The PKI consists of:
OpenVPN supports bidirectional authentication based on certificates, meaning that the client must authenticate the server certificate and the server must authenticate the client certificate before mutual trust is established.
Both server and client will authenticate the other by first verifying that the presented certificate was signed by the master certificate authority (CA), and then by testing information in the now-authenticated certificate header, such as the certificate common name or certificate type (client or server).
This security model has a number of desirable features from the VPN perspective:
Note that the server and client clocks need to be roughly in sync or certificates might not work properly.
The user has the option to generate ALL the required keys directly from FreshTomato GUI using the button Generate Keys or just simply using the easy-rsa tool provided by OpenVPN software and following the instruction available on the following resources:
Please note that using NVRAM space to store the certificate values may be expensive specially for those routers with limited RAM. The certificates will consume about 14KB of NVRAM space, so if your router has limited NVRAM available may be a good idea to store the certificates in JFFS or a mount in your router. Please consider all the security risks before following this procedure as the certificates may be accessible if you have Samba or NFS sharing enabled.
Here is an example of how to include the certificates in your Custom Configuration field if you do not want to use NVRAM space.
#Path names and filenames below are used only as example dh /jffs/certs/dh.pem #Contains Diffie-Hellman parameters cert /jffs/certs/srv.crt #Contains Server Certificate + Server Key ca /jffs/certs/ca.crt #Contains CA Key
Please note that since FreshTomato does not use TLS with elliptic crypto curves, you must configure the Diffie-Hellman parameters
BEWARE: One common mistake when setting up a new CA is to place all the CA files on the OpenVPN server. DO **//NOT//** DO THAT! A CA requires a private key which is used for signing the certificates your clients and servers will use. If you loose control of your CA private key, you can no longer trust any certificates from this CA. Anyone with access to this CA private key can sign new certificates without your knowledge, which then can connect to your OpenVPN server without needing to modify anything on the VPN server. Place your CA files on a storage which can be offline as much as possible, only to be activated when you need to get a new certificate for a client or server.
The files you need to copy out from a CA are just 3 files for each client and server.
Private key (often a .key or .pem file) Certificate (often a .crt or .pem file) CA certificate (also a .crt or .pem file)
The server in addition needs a DH parameters file.
You should avoid generating keys on any devices which does not have a good entropy source for random data. This includes most of the common wifi routers and similar embedded devices. In many cases virtual machines also does not have a good entropy source or it can be manipulated by the hypervisor. Try as far as possible to generate keys and DH parameters on bare-metal equipment.
To better understand how PKI work, have a look at this introduction: https://github.com/OpenVPN/easy-rsa/blob/master/doc/Intro-To-PKI.md
Within the CA, you can also revoke certificates as needed. Using the CA management tool of your choice, you should be able to generate a Certificate Revocation List (CRL file). By adding this to the OpenVPN server, all client certificates will be checked against this revocation list. Clients which have their certificates listed in the CRL will not be able to connect. This is a common way to disable access to a VPN service on a per user level.
Add this line to the OpenVPN server configuration:
crl /full/path/to/crl.pem
If you want to access particular network resources on other IP addresses via the VPN tunnel, you need to add network routes. A network route tells your operating system where it needs to send the network traffic when you want to access certain resources. An operating system can handle multiple routes via multiple gateways at the same time. So if you have a server on 192.168.1.10 behind your VPN server and you want to access this server via the VPN, you need to tell OpenVPN to configure a route for either a specific host or a network range to go via the tunnel.
So to configure this, you need to add one line in the server configuration and restart server and client.
push "route 192.168.1.0 255.255.255.0"
When the client now connects, the server tells the VPN client that it should route all traffic for IP addresses in the 192.168.1.XXX scope via the VPN connection.
This is a very basic setup. And when we now start on the routing part, the VPN setup is mostly done. All you need now is to add the needed routes you need, just like you would do for normal TCP/IP routing.
BEWARE: Remember that you also need to consider what is called “return routes”. If your VPN client can access a host behind your VPN server, it does not mean that the host behind the VPN server will send the response via the same route. So you need to ensure that your hosts behind your VPN server also knows which gateway to use for your VPN. Nowadays this is most commonly fixed by adding a route on your existing default gateway. And if you run OpenVPN on an existing gateway, you have this return route already impllicitly configured.
For a more detailed example using routing, see the Using routing section in the 'Bridiging and routing' wiki page.
It is possible to route absolutely all network traffic over the VPN. The configuration in OpenVPN is fairly simple. But you will need to investigate how to configure NAT on your VPN server for the virtual tun adapter.
You can either push such a “route everything over VPN” via the server, or you can add it explicitly in the client configuration. Do not use both at the same time.
Server push:
push "redirect-gateway def1"
Client configuration alternative:
redirect-gateway def1
OpenVPN v2.3 and later supports IPv6. To set up IPv6 in the tunnel is pretty much the same as for the IPv4 examples we already have covered. You need to use the –server-ipv6 and –route-ipv6 options to configure IPv6.
For example, adding this will configure the IPv6 addresses for server and clients:
server-ipv6 2001:db8:cada::/64
You can use the –route-ipv6 option, either pushing it from the server or using it directly in the client configuration, just as you can with the –route option. The syntax is similar too:
route-ipv6 2001:db8:daca::/64
There are a few more things which may need to be configured, but those are mostly outside of OpenVPN. The most common issues are related to adjusting your operating system to allow forwarding of packets and configuring the firewall properly.
Configuring firewall is so different between Linux and other Unix based OSes, in addition several Linux distributions have their own tools to manage iptables. So it is better to read the manuals for the firewall configuration on your operating system.