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

• When using a TAP adapter, the full Ethernet frame is encapsulated. This causes a slightly larger overhead.
• All the machines that are connected to a TAP-style network form a single broadcast domain.
• If bridging is needed, a TAP-style tunnel is required.

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:

• Virtual-machine networking
• Virtual Private Networks (VPNs)
• Connections between real machines and network simulations (basically, network behaviour modelled by software)
• NAT (Network Address Translation – the process of remapping an IP address into another)

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.

TUN

Advantages

• TUN has less traffic overhead.
• In terms of VPNs, it only transports traffic that is destined for the VPN client.
• It only handles layer 3 IP packets.

Disadvantages

• It cannot be utilized in network bridging.
• TUN doesn’t normally transport broadcast traffic.
• TUN is limited to transporting IPv4 (OpenVPN 2.3 does add IPv6 support).

TAP

Advantages

• TAP can be used in network bridging.
• It only handles the transport of network protocols (like IPv4 and IPv6, for example).
• Even though it’s a virtual network adapter, it behaves like a real one.

Disadvantages

• All the packets transported by TAP feature the overhead of Ethernet headers.
• TAP is known to feature poor scalability.
• When it comes to VPN tunnels, TAP tends to cause more broadcast overhead.

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

• Faster speeds - UDP is significantly faster than TCP.
• Preferred connection for media streaming, VoIP and playing games online.
• Lower reliability – On rare occasions UDP can drop packets.

TCP OpenVPN Protocol

• Better reliability – TCP offers more stable connections as it guarantees delivery of packets
• Bypass Firewalls – TCP is rarely blocked since it runs on common ports. TCP VPNs can bypass even the strictest corporate/country firewalls.
• Slower speeds – TCP features higher encryption methods that tend to slow transfer rates compared to UDP

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

• Auto: means the firmware takes care of creating every required firewall rules, NAT rules for the tunnel, etc…
• Custom: means nothing is configured by the router, you have to do everything yourself manually.
• External: will block LAN access (*To be Confirmed).

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

• TLS – OpenVPN will use TLS authorization mode. The Certificates can be generated in the Keys section. You will need to configure the certificates in the KEYS tab
• Static Key – The OpenVPN will use static key (pre‐shared) authorization mode.
• Custom - If this option is selected, the user will need to configure all the Authentication parameters in the custom options field available in the Advanced tab

Note: Static key configurations offer the simplest setup, and are ideal for point-to-point VPNs or proof-of-concept testing.

Static Key advantages

• Simple Setup
• No X509 PKI (Public Key Infrastructure) to maintain

Static Key disadvantages

• Limited scalability — one client, one server
• Lack of perfect forward secrecy — key compromise results in total disclosure of previous sessions
• Secret key must exist in plaintext form on each VPN peer
• Secret key must be exchanged using a pre-existing secure channel

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:

• AES-256-GCM
• AES-128-GCM
• AES-256-CBC
• AES-128-CBC

Please note the the above are the recommended ciphers to avoid any possible SWEET32 attack documented on the following resources:

• https://community.openvpn.net/openvpn/wiki/SWEET32
• https://sweet32.info/

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:

• a separate certificate (also known as a public key) and private key for the server and each client, and
• a master Certificate Authority (CA) certificate and key which is used to sign each of the server and client certificates.

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:

• The server only needs its own certificate/key — it doesn’t need to know the individual certificates of every client which might possibly connect to it.
• The server will only accept clients whose certificates were signed by the master CA certificate (which we will generate below). And because the server can perform this signature verification without needing access to the CA private key itself, it is possible for the CA key (the most sensitive key in the entire PKI) to reside on a completely different machine, even one without a network connection.
• If a private key is compromised, it can be disabled by adding its certificate to a CRL (certificate revocation list). The CRL allows compromised certificates to be selectively rejected without requiring that the entire PKI be rebuilt.
• The server can enforce client-specific access rights based on embedded certificate fields, such as the Common Name.

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:

• https://openvpn.net/community-resources/how-to/
• https://wiki.archlinux.org/index.php/Easy-RSA
• https://wiki.gentoo.org/wiki/Create_a_Public_Key_Infrastructure_Using_the_easy-rsa_Scripts#Create_CA_certificate

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.