The OpenVPN Server menu allows viewing and configuration of settings for FreshTomato's OpenVPN Server.
Two distinct VPNs can be created, each using TUN/TAP virtual interfaces. Connections are TLS-encrypted.

Start with WAN: Checking this makes OpenVPN Server run each time the WAN interface comes up. This is suitable if OpenVPN server needs to be available 24/7.

Start Now: If Start with WAN is not checked, clicking on this makes the OpenVPN server start immediately.

VPNs use virtual (software) network devices to simulate physical network adapters. OpenVPN has two main types of virtual interfaces:

TUN, (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.

Advantages

• Has less overhead.
• TUN only transports traffic destined for the VPN client.
• TUN only handles layer 3 IP datagrams.

Disadvantages

• Cannot be used to bridge networks.
• Doesn’t normally transport broadcast traffic.
• Limited to transporting IPv4 (OpenVPN 2.3 adds IPv6 support).

TAP, (“network TAP”), simulates a layer 2, link layer device to create a network bridge. TAP carries Ethernet frames. Since TAP allows full Ethernet frames to pass through the tunnel, it also supports non-routable protocols like IPX and AppleTalk.

Other important differences include:

• TAP has slightly more overhead, since it encapsulates the full Ethernet frame.
• All devices connected to a TAP-based network form a single broadcast domain,
  because TAP acts as a bridge.
• Since TUN is used with routing, it can help networks to intercommunicate,
  while still remaining separate.

Common applications of TUN/TAP include:

• VM networking.
• Connections between real machines and network simulations
  (network behaviour modelled by software).
• NAT (Network Address Translation).

Advantages

• Can be used to bridge networks.
• Only handles the transport of network protocols, such as IPv4 and IPv6.
• Behaves like a real network adapter, even though it’s virtual.

Disadvantages

• All packets TAP transports include the overhead from Ethernet headers.
• TAP Tends to scale poorly.
• TAP tends to cause more broadcast overhead.

Both clients and server must use the same Interface type(s). You cannot use TAP on clients and TUN on servers or vice versa.

• LAN (br0)
• LAN1 (br1)
• LAN2 (br2)
• LAN3 (br3)

This option appears 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. (Default: LAN (br0) ).

OpenVPN can run over TCP or UDP transport protocols.

UDP OpenVPN Protocol

• Faster — UDP is significantly faster than TCP.
• Preferred connection for media streaming, VoIP and playing games online.
• Lower reliability — Occasionally, UDP can drop packets.

TCP OpenVPN Protocol

• Higher reliability — TCP offers more stable connections, since it
  guarantees delivery of packets.
• Bypass Firewalls — TCP is rarely blocked, since it runs on common ports.
  TCP VPNs can bypass even strict corporate/government firewalls.
• Lower speed — TCP's higher encryption tends to slow transfer rates
  when compared with UDP.

This sets the port on which the OpenVPN server will listen on the router's WAN interface. Make sure to configure firewall / IPTables rules to allow the traffic through this port. (Default: 443).

• Auto — FreshTomato creates all firewall and NAT rules required for the tunnel.
• Custom — FreshTomato configures no firewall/NAT rules. The Administrator
  must create them manually.
• External Only — This blocks LAN access (*To be Confirmed).

OpenVPN allows peers to authenticate each other using a Static (Pre‐Shared) Key or certificates. In client‐server configuration, OpenVPN allows the server to release an authentication certificate for each client, using signature and certificate authority. OpenVPN uses the OpenSSL encryption library, as well as the SSLv3/TLSv1 protocol. It contains many security and control features.

This option selects the authorization mode for the OpenVPN Server.

• TLS — This setting uses Transport Layer Security authorization mode.
  This is the most secure authorization mode. Certificates can be generated in the Keys tab.
  Certificates are also configured in the KEYS tab. An SSL session is established
  with bidirectional authentication. Each side must present its own certificate.
  OpenVPN uses a reliable transport layer on top of UDP, because SSL/TLS
  is designed to operate over a reliable transport. Once each peer has its set of keys,
  tunnel forwarding begins.

• Static Key — This option uses Static Pre-Shared key (pre‐shared or “PSK”) authorization mode.
  This mode offers the simplest setup, ideal for point-to-point VPNs or testing.
  However, there are security compromises. The static key size is fixed at 2048 bits.
  The key size doesn't correlate with the encryption level that protects the data
  between VPN peers. The –cipher and –keysize parameters set the encryption key size.
  Static Keys have security limitations. While easier to set up than an X.509 public key infrastructure,
  Static Keys lack Perfect Forward Secrecy. Since the key isn't automatically rotated,
  an attacker who gains access to the key may be able to decrypt any intercepted
  past or future communication using that key. Without automatic key rotation, there is a higher
  chance the key might be brute-force cracked for long-lived connections.

• Custom — The administrator must configure all authentication parameters in the
  Advanced Tab /Custom Settings field.

Static Key

Advantages

• Simple Setup.
• No X.509 PKI (Public Key Infrastructure) to maintain.

Disadvantages

• Limited scalability — one client, one server.
• Lacks Perfect Forward Secrecy — this compromise can result
  in total disclosure of previous sessions.
• The secret key is stored in plaintext on each VPN peer.
• The secret key must be exchanged using a pre-existing secure channel.

This menu appears automatically if TLS Authorization mode is selected.

This option specifies how FreshTomato will generate the tls-auth configuration parameter where a direction constant needs to be given. This decides which set(s) of HMAC keys will be used (HMAC-send, cipher-encrypt, HMAC-receive, cipher-receive).

• Disabled — No tls-auth will be used on the server. No direction is set.
• Bi-directional Auth — [Direction] is set to 2.
  The HMAC-send and cipher-encrypt keys will be used.
• Incoming Auth (0) — [Direction] is set to 0.
  HMAC keys won't be used on this server.
  However, they may be used on remote endpoints.
• Outgoing Auth (1) — [Direction] is set to 1.
  The HMAC-send HMAC keys will be used.
• Encrypt Channel — [Direction] is set to 3.
  The HMAC-send, cipher-encrypt, and HMAC-receive HMAC keys will be used.
• Encrypt Channel v2 — [Direction] is set to 4.
  HMAC-send, cipher-encrypt, HMAC-receive and cipher-receive will all be used.

TLS requires a multi-packet exchange before it authenticates a peer. During this exchange, OpenVPN allocates memory and CPU resources to the potential peer. The potential peer exposes parts of OpenVPN and the OpenSSL library to the packets it is sending. Most successful network attacks today try to 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 defence is always good programming. One of the main goals in writing OpenVPN was to prevent buffer overflow attacks. However, many of the most widely-used network applications still occasionally fall to buffer overflow attacks.

OpenVPN's second line of defence is an authentication layer on top of the TLS Control channel. At this layer, every packet on the control channel is authenticated by an HMAC signature and a Unique ID. This prevents replay attacks. The signature also helps protect against Denial of Service (DoS) attacks. When an unauthenticated client has limits on how much resources it can use, there is less vulnerability to DoS attacks.

Enabling TLS Control Channel Security makes FreshTomato sign every control channel packet with an HMAC signature. This includes packets sent before the TLS layer has authenticated its peer. Packets without the correct signature will be immediately dropped on receipt. In this way, such packets don't have a chance to consume additional system resources.

However, the feature is optional. The key file used with –tls-auth gives a peer only the power to initiate a TLS handshake. It is not used to encrypt or authenticate any tunnel data. Encrypt Channel should be used instead if you want to use the key file to both authenticate and encrypt the TLS control channel.

(Default: Disabled).

Auth Digest (Authentication Digest) is an authentication system which reduces the risks of the plaintext method used with Basic authentication. With Auth Digest, the client sends a hash of its data over the network. Thus, the client's user name and password are never sent in plaintext over the network. This reduces the risk that logon credentials could be snooped.

If Auth Digest is set to a value other than None, OpenVPN will authenticate data channel packets and tls-auth control channel packets with HMAC. To do this, it will use a message digest algorithm (SHA1, by default ). HMAC is a common Message Authentication Code 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 order. A packet is first encrypted, then the resulting ciphertext has HMAC applied against it. This helps prevent 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. To disable authentication, set alg=none.

For basic information on HMAC, see: https://www.tutorialspoint.com/cryptography/message_authentication.htm

For a more advanced discussion, see: http://www.cs.ucsd.edu/users/mihir/papers/hmac.html

This option appears when the TUN interface type is selected. In this field, you enter the subnet and netmask used to assign addresses to OpenVPN clients.

This option appears when the TAP interface type is selected. This specifies which method will be used to assign addresses to OpenVPN clients.

DHCP * — When checked, DHCP will assign addresses to your OpenVPN clients from your normal DHCP pool.
When unchecked, the Client Address Pool field appears. In this field, you can create a special pool of addresses for your VPN clients.

If set greater than zero, a watchdog polls connectivity every n minutes, to verify that OpenVPN is activated. If it finds that OpenVPN is not activated, it will restart the OpenVPN service. If set to zero, the watchdog is disabled.

If checked, this instructs OpenVPN clients to redirect all their Internet traffic through this server. In other words, this server becomes their default gateway. If unchecked, routing will need to be configured on each client.

The OpenVPN server can push DHCP options like DNS and WINS server addresses to clients (with limitations). As is, Windows clients can accept pushed DHCP options. Non-Windows clients can accept options by using a client-side up script which parses the foreign_option_nenvironmental variable list. See the OpenVPN Linux man(ual) page for non-Windows foreign_option_n documentation and script examples.

This selects which cipher algorithm is used to encrypt data channel packets. The default is BF-CBC, (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, such as the SWEET32 attacks. See https://community.openvpn.net/openvpn/wiki/SWEET32 for details. For this reason, support for BF-CBC, DES, CAST5, IDEA and RC2 ciphers will be removed starting in OpenVPN 2.6.

• Disable: * Disables encryption.
• Enabled (with fallback): This setting uses the cipher set in the Legacy/fallback cipher field.
• Enabled: Choosing this option removes the Legacy/fallback cipher field.

This field cannot be edited. It displays which ciphers can be negotiated during the handshake between OpenVPN Client and Server.

The ciphers available in existing firmware are:

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

Please note the recommended ciphers to avoid SWEET32 attacks:

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

This field defines which cipher to use as a fallback, in case cipher negotiation between client and server fails using the available ciphers.

• Disabled * (Default)
• LZO
• LZ4

This enables a compression algorithm. LZO and LZ4 are different compression algorithms. LZ4 generally offers the best balance between performance and low 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 is set to Disabled, compression will also be disabled. However, packet framing for compression will still be enabled, allowing a different setting to be pushed later.

Security Considerations

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, they might be able to extract the secret if compression is enabled. For example, the CRIME and BREACH attacks on TLS leverage compression to break encryption. If you can't be sure the above problems don't apply to your traffic, you are advised to disable compression.

This specifies how many seconds (n) will pass before OpenVPN renegotiates the data channel key (Default=3600). When using dual-factor authentication, the default value may cause the end user to be challenged to reauthorize once per hour.

This option can be used on both client and server. Whichever host uses the lower value will trigger the renegotiation. It's 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. In this case, renegotiation will still occur once every 3600 seconds. The solution is to increase –reneg-sec on both 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.

This option allows for bidirectional site-to-site TLS VPNs with no Custom Configuration or init scripts.

Choosing this option displays a table in which to enter the Common Name (from when you generated TLS certificates), Subnet (optional), and Netmask (optional). If you enter the Client Subnet and Netmask, your server LAN will be able to communicate with your client LAN whenever it's connected. Do NOT select the NAT option on the client router. Without this <fix me>, the network will only communicate in client-server mode.

If you select the “Allow Client↔Client” option, a checkbox appears in the table. When selected, that checkbox allows other clients (or client LANs) to communicate with this client LAN.

At this point, you can have multiple sites all connected, with communication between any of them you choose. 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 wish to allow access to it), enter it into the table and leave the Subnet/Netmask fields blank.

You can further customize your OpenVPN server by changing its server port from the default 1194. You can also change the auth digest and encryption cipher to whatever you wish. Using AES-128-CBC and auth digest of SHA1 are sufficient encryption for maintaining proper security when connecting to your Server.

Here, you can specify the custom configuration to be used by the OpenVPN server.

Please refer to https://openvpn.net/community-resources/reference-manual-for-openvpn-2-4/ for information about custom parameters that can be used.

You MUST configure the certificates if you have chosen TLS authorization mode.

Instead of a static key, you can allow the machines to use TLS to negotiate an encryption key and an encryption algorithm. During the TLS handshake process, one machine acts as server and the other as client. Once the handshake is completed, the OpenVPN interaction is on a peer-to-peer basis. <Meaning what, precisely?>

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.