Select this option if you require OpenVPN server to be available automatically after each WAN UP signal. This may be needed if you require your OpenVPN server to be available 24/7. If this option is not ticked, then you will need to click on the button START NOW in case you need the server to be available.
A TUN device is used mostly for VPN tunnels where only IP-traffic is used. A TAP device allows full Ethernet frames to be passed over the OpenVPN tunnel, hence providing support for non-IP based protocols such as IPX and AppleTalk. Differences between TUN and TAP
TAP is used to simulate a link layer device, which represents a group of communication protocols and methods that run on a link a specific host is connected to. In the 7-layer OSI (Open Systems Intercommunication) computer networking model, a link layer can often be considered a mix between layer 1 (the physical layer) and layer 2 (the data link layer).
Overall, TAP works with layer 2 packets, handling the transmission of data frames (a frame is layer 2’s Protocol Data Unit) between 2 nodes that share a physical layer (layer 1 of the OSI). Ethernet frames are a good example of the kind of data handled by TAP. Furthermore, TAP is also used for network bridging, the act of connecting 2 separate networks as if they were one.
TUN is responsible for simulating a network layer device (essentially layer 3 in the OSI model). The main functions, in this case, would include host addressing, message forwarding, traffic control, and connectionless communication. The Protocol Data Unit TUN works with is called a “packet.” Internet Protocol packets are an example of the kind of data TUN works with.
Since layer 3 is responsible for port forwarding (which includes routing through intermediate routers), TUN is also used with routing, which means it can help multiple networks communicate in an independent manner while remaining separate at the same time. Common applications of TUN/TAP include:
TUN and TAP – Pros and Cons
Not every TUN/TAP application out there uses both virtual network kernel devices. Some of them only rely on one, while others allow their users to manually switch between them. As a result, it’s important to understand what pros and cons characterize each kernel, as there’s more to them than just stating that TUN utilizes layer 3 and TAP utilizes layer 2.
The device type must be identical on server and clients. You cannot use TAP on clients and TUN on servers or vice versa.
This option will become available if you have selected TAP as interface Type. Select the VLAN you want to bridge the clients that connect to your OpenVPN server.
OpenVPN can run over either TCP or UDP transport protocols. We offer multiple UDP & TCP OpenVPN ports on all our VPN servers.
UDP OpenVPN Protocol
TCP OpenVPN Protocol
This is the port the OpenVPN server will be listening on the WAN interface of your router. Make sure you have your firewall / IPTables configured to allow the traffic through this port. Default value is 443
OpenVPN allows peers to authenticate each other using a Static Key (pre‐shared key) or certificates. When used in a multi‐client‐server configuration, it allows the server to release an authentication certificate for every client, using signature and certificate authority. It uses the OpenSSL encryption library extensively, as well as the SSLv3/TLSv1 protocol, and contains many security and control features.
Select in this field the authorization mode for the OpenVPN Server: TLS, Static Key or Custom
Note: Static key configurations offer the simplest setup, and are ideal for point-to-point VPNs or proof-of-concept testing.
Static Key advantages
Static Key disadvantages
This field will automatically appear if you have selected TLS Authorization mode.
TLS requires a multi-packet exchange before it is able to authenticate a peer. During this time before authentication, OpenVPN is allocating resources (memory and CPU) to this potential peer. The potential peer is also exposing 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. Of course the first line of defense is always to produce clean, well-audited code. OpenVPN has been written with buffer overflow attack prevention as a top priority. But as history has shown, many of the most widely used network applications have, from time to time, fallen to buffer overflow attacks.
So 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:
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.
push "redirect-gateway def1"
Client configuration alternative:
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:
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:
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.