Here, you can view/configure settings for OpenVPN Servers via the web interface. A custom configuration area allows more settings customization.

OpenVPN is an evolving VPN implementation using SSL/TLS security.

It has several advantages over some older protocols, including:

• Flexible configuration options
• It is quite forgiving
• It tries to keep backwards compatibility with older versions.

However, there are still differences between versions. For example, clients and servers may be configured on different versions. Encryption algorithms may be negotiated differently among versions. FreshTomato 2024.3 includes OpenVPN 2.6.12. For details, see the OpenVPN documentation/support forums: https://build.openvpn.net/man/openvpn-2.6/openvpn.8.html

FreshTomato can run 2 concurrent OpenVPN Server instances, with different configurations (“Server 1”/“Server 2”).

Each server menu has its own interface tabs:

• Basic
• Advanced
• Keys
• Status

The Basic and Advanced Tabs are used to configure the general setup of servers and configuration file options. The OpenVPN server reads options settings when it starts. It first reads Options set in the web interface, then it reads options.

In the Keys tab you enter (externally-sourced) encryption keys used. You can also generate keys directly there, for setups that don't get keys from an external source.

When the OpenVPN server is running, the “Status” tab shows connected clients, routing and statistics.

Start with WAN: makes OpenVPN Server run whenever the WAN interface comes up. This is used to make OpenVPN run 24/7.

Start Now: starts the OpenVPN server immediately if Start with WAN is unchecked, or the server isn't running.

VPNs use virtual (software) network devices to emulate physical network adapters.

OpenVPN has 2 main types of virtual interfaces:

TUN, (“network TUNnel”), emulates a network layer device.

TUN operates at OSI layer 3 to carry IP datagrams. It is used with routing. In general, TUN is used for VPN tunnels where only IP is used.

Advantages

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

Disadvantages

• Can't be used to bridge networks.
• Doesn’t normally transport broadcast traffic.
• Limited to transporting IPv4 (v2.3 adds IPv6 support).

TAP, (“network TAP”), simulates a layer 2, link layer device to create a bridge.

It carries full Ethernet frames through the tunnel. It supports non-routable protocols (IPX/ AppleTalk).

Other important differences include:

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

Common applications of TUN/TAP include:

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

Advantages

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

Disadvantages

• All packets transported by TAP include Ethernet header overhead.
• Tends to scale poorly.
• Tends to cause more broadcast overhead.
• Isn't supported by some clients.

Clients/server must use the same Interface types. You can't use TAP on clients and TUN on servers.

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

This appears when TAP is chosen. Here, you choose the VLANs to which to bridge clients that connect to the OpenVPN server.

OpenVPN can run over TCP or UDP transport protocols.

UDP OpenVPN Protocol

• Faster - it's significantly faster than TCP.
• Is the preferred protocol for streaming, VoIP and online gaming.
• Lower reliability - occasionally, it can drop packets.

TCP OpenVPN Protocol

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

Here, set the port on which OpenVPN server listens on the WAN interface.

You must set firewall / IPTables rules to let traffic through the port. The IANA assignment for OpenVPN is port 1194, but other ports may be used.

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

This lets you set the authorization mode for the OpenVPN Server.

OpenVPN lets peers authenticate each other using a Static (Pre‐Shared) Key or certificates.

In client‐server configuration, The OpenVPN server releases an authentication certificate for each client, using signature/certificate authority.

OpenVPN uses the OpenSSL encryption library, and the SSLv3/TLSv1 protocol. It has many security and control features.

• TLS - uses Transport Layer Security authorization mode.
  It's the most secure authorization mode.
  
  Certificates can be generated and 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 over UDP, because
  SSL/TLS is designed to operate over reliable transport. Once each
  peer has its own set of keys, tunnel forwarding begins.

• Static Key - uses Pre-Shared key (“PSK”) authorization mode.
  This has the simplest setup, ideal for point-to-point VPNs or testing.
  
  However, security compromises exist. The static key size is fixed
  at 2048 bits. Key size doesn't correlate with the encryption level that
  protects the data between VPN peers.
  
  Static Keys have security limitations. They're easier to set up than an
  X.509 PKI, but lack Perfect Forward Secrecy. Since the key isn't
  automatically rotated, an attacker with access to the key may be able
  to decrypt intercepted past/future communication using that key.
  Without automatic key rotation, it's more likely the key might be
  brute-force cracked for long-lived connections.

• Custom - the administrator must set all authentication parameters
  in the Advanced Tab/Custom Settings field.

Static Key

Advantages

• Requires simple set up.
• No X.509 PKI (Public Key Infrastructure) to maintain.

Disadvantages

• Has limited scalability. Only 1 client and 1 server can exist.
• Lacks Perfect Forward Secrecy. This 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 on an existing secure channel.

This menu appears if TLS Authorization mode is chosen. It lets you choose the security measures to apply to the control channel.

TLS authentication/encryption options require you to generate and distribute some additional static keys for the server/clients. Both tls-auth and tls-crypt require you to have at least one pre-shared key used by server and clients.

By contrast, with Tls-crypt-v2, you must generate specific keys for each client. (Ref. OpenVPN –tls-auth, –tls-crypt, –tls-crypt-v2 and –secret).

• Disabled - no additional TLS authentication/encryption is applied.

• Bi-directional Auth - (tls-auth) [Direction] is set to 2.
  Will use HMAC-send and cipher-encrypt keys.

• Incoming Auth (0) - (tls-auth) [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) - (tls-auth) [Direction] is set to 1.
  Will use HMAC-send HMAC keys.

• Encrypt Channel - (tls-crypt) [Direction] is set to 3.
  Will use HMAC-send/HMAC-receive and cipher-encrypt keys.

• Encrypt Channel v2 - (tls-crypt-v2[Direction] is set to 4.
  Uses HMAC-send/HMAC-receive, and cipher-encrypt/cipher-receive.

TLS exchanges multiple packets to authenticate a peer. In the 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 sends.

Most current network attacks exploit bugs in programs (like overflow attacks) or force a program to consume so many resources it becomes unusable. The first line of defense is good programming. Preventing buffer overflow attacks was a main goal in designing OpenVPN. Even so, many widely-used network applications still fall to buffer overflow attacks.

The second line of defense is tls-auth, an authentication layer on top of the TLS Control channel. There, every control channel packet is authenticated by an HMAC signature and a Unique ID. This prevents replay attacks. The signature also helps protect against DoS attacks. DoS attacks are less likely when an unauthenticated client is limited in the resources it may use.

Enabling TLS Control Channel Security (Encrypt Channel / tls-crypt) 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 immediately be dropped on receipt. As a result, those packets have no chance to consume more system resources.

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

This authentication system reduces the risks of the plaintext method when Basic authentication is used.

With Auth Digest, a client sends a hash of its data over the network. The client's username/password are never sent in plaintext, reducing the risk that someone might snoop the logon credentials.

With any setting except None, OpenVPN authenticates data channel packets and tls-auth control channel packets with HMAC. It uses a message digest algorithm (default: SHA1) for this. HMAC is a common Message Authentication Code algorithm.

HMAC produces a digital signature using:

• A data string
• A secure hash algorithm and;
• A key

The OpenVPN data channel protocol uses Encrypt-then-Mac order.

1. First, a packet is encrypted, then;
2. The resulting ciphertext has HMAC applied against it.

This method helps prevent padding oracle attacks.

If an AEAD cipher mode (say, GCM) is chosen, the specified –auth algorithm is ignored for the data channel. The AEAD's cipher authentication method is used instead. However, alg still specifies the digest used for tls-auth.

In Static Key encryption mode, the HMAC key is included in the key file. 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 drops that packet. Typically, HMAC adds 16 or 20 bytes per packet.

For basic HMAC information, see: TutorialsPoint: Message Authentication Code

This appears when TUN interface type is chosen. Here, enter the subnet/netmask used to assign addresses to OpenVPN clients.

If TUN is selected, the VPN topology is set to “subnet”. This mode allocates a single IP address per client connecting from the subnet range. If you need another OpenVPN topology, that must be set in the custom configuration field. (Ref. OpenVPN option “–topology”. Successful overriding of “–topology subnet” with a different topology in custom configuration to be confirmed.)

This option appears if TAP interface type is chosen. It sets the method used to assign addresses to OpenVPN clients.

DHCP - if checked, DHCP will assign addresses to OpenVPN clients from the normal DHCP pool.
If unchecked, the Client Address Pool field appears, prompting you for a special pool of VPN client addresses.

If set greater than zero, a watchdog polls connectivity every n minutes, to verify OpenVPN is running. If it finds OpenVPN isn't running, it restarts the OpenVPN service. If set to “0”, the watchdog is disabled.

[TBD]

This instructs OpenVPN clients to redirect all Internet traffic through this server. In other words, this server becomes their default gateway. If disabled, the client performs its default routing.

On supported platforms, this sets the client DNS server to the local FreshTomato DNS. (Ref.OpenVPN “–dhcp-option”)

This contains a colon-delimited list of ciphers in the order they'll be negotiated with clients. If nothing is defined, the server defaults to “AES-256-GCM:AES-128-GCM”.

The first cipher in the list that the client supports will be pushed to clients that support cipher negotiation. If no common cipher is found during negotiation, the connection is terminated.

Available ciphers include:

• CHACHA20-POLY1305
• AES-128-GCM
• AES-256-GCM
• AES-128-CBC
• AES-256-CBC

(Ref. OpenVPN “–data-ciphers”)

• Disabled * (Default)
• LZO
• LZ4

This enables either the LZO or LZ4 compression algorithm. Generally, LZ4 offers the best performance/CPU usage balance. For backwards compatibility with OpenVPN versions earlier than v2.4, use “LZO”. LZO is identical to the older OpenVPN option “–comp-lzo yes”.

Choosing Disabled disables compression. However, packet framing for compression is still enabled, allowing a different setting to be pushed later.

Security Considerations

Combining compression and encryption is tricky. If an attacker knows or is able to control (parts of) the plaintext of packets containing secrets, they might be able to extract the secret if compression is enabled. For example, the CRIME and BREACH attacks on TLS use compression to break encryption. If you're not sure the above problems don't apply to your traffic, disable compression.

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

This can be used on both client and server. Whichever host uses the lower value triggers the renegotiation. It's a common mistake to set this to a higher value on either client or server, while the other end is set with the default. In this case, renegotiation still occurs once every 3600 seconds. The solution is to increase –reneg-sec on both client and server, or set it to “0” (disabled) on one side, and to your preferred value on the other.

If enabled, this lets you apply individual client options. If disabled, the option to allow client certificates with the same common name is applied.

(Ref.OpenVPN “–duplicate-cn”)

With this selected, options appear to enable you to configure access between VPN clients.

The Allow Client↔Client option lets an OpenVPN client access the other OpenVPN client's network, and/or the network behind each OpenVPN client. By default, OpenVPN blocks network access between OpenVPN clients.

When Allow Client↔Client is enabled on the server, you can limit the networks available to clients. Use the “Allow Only These Clients” table to specify and limit the access your client will have over the network. (Ref. OpenVPN “–client-to-client”)

To use Client-Specific Options, each client must have a certificate with a unique, common name (“CN”). This is used to identify which client rule to apply. By default, duplicate client names are rejected.

If you still need client-specific options and don`t want to use unique client certificates, allow usernames as a common name, or duplicate common names. However, using usernames or duplicate common names may lead to unexpected results if you're expecting different client rules.

Consider using one of these phrases in your Custom Settings:

duplicate-cn

Or you could use:

username-as-common-name

You can use the push checkbox in the clients table to push routes to clients. If it is disabled, you must set routes separately in each client configuration. The check box is not applicable when Allow Client↔Client is disabled.

You can set other client-specific options in the Custom Configuration field, and a Client Configuration Directory. Enabling client-specific options creates an internal Client Configuration Directory. That directory holds client-specific options set in the web interface. (Ref. OpenVPN “–client-config-dir”)

[To be confirmed whether multiple Client Config Dirs are read or whether the custom Client Config Dir replaces the 'internal' CCD]

Here, you can specify a custom configuration for the OpenVPN server to use.

For details about valid custom parameters, please see:
https://build.openvpn.net/man/openvpn-2.6/openvpn.8.html
.

If TLS authorization mode is selected, you MUST configure certificates.

Instead of using a static key, you can let the machines use TLS to negotiate an encryption key/algorithm. During the TLS handshake, one machine acts as server and the other as client. When the handshake is complete, OpenVPN interaction is on a peer-to-peer basis.

For a TLS handshake, both “server” and “client” must have their respective certificates. Also, you must generate Diffie-Hellman parameters for the “server”. This will finally lead to the creation of a shared secret number. You will generate your own certificates.

Every certificate is issued by a Certificate Authority, (“CA”), so you must create one. You can create a CA, certificates, and Diffie-Hellman parameters in FreshTomato.

The first step to building an OpenVPN 2.x setup is to create a Public Key Infrastructure.

A PKI consists of:

• A separate certificate (public key) and private key for the server
  and for each client
• A master CA certificate and key used to sign each of the server
  and client certificates

OpenVPN uses bidirectional, certificate-based authentication. Client/server must authenticate the other's certificates before they establish mutual trust.

Both server and client authenticate each other:

1. By verifying the certificate presented was signed by the master
   certificate authority (CA).
2. By testing the information in the authenticated certificate header.
   That includes the certificate common name (CN) or certificate
   type (client or server).

This security model has several desirable features:

• The server only needs its own certificate/key. It doesn’t need to know
  the certificate of every client that might connect to it.
  
  
• The server will only accept clients whose certificates were signed
  by the master CA certificate (which we'll generate below).
  
  Because the server can verify this signature without needing access
  to the CA private key itself, you can store the CA key on another machine.
  It can even be stored on a device not connected to the network.
  This is crucial, since it's the most sensitive key in the entire PKI.
  
  
• If a private key is compromised, it can be disabled by adding its certificate
  to a CRL (Certificate Revocation List). This allows compromised certificates
  to be selectively rejected without requiring the entire PKI be rebuilt.
  
  
• The server can enforce client-specific access rights based on fields
  embedded in the certificates, such as the Common Name.

Note that server and client clocks need to be roughly synchronized for certificates to function properly.

The Generate Keys button generates all necessary keys directly from the web interface.

It can also be done at the command-line with OpenVPN's “easy-rsa” tool using these instructions:

• OpenVNP Community: HOWTOs
• ArchLinux Wiki: Easy-RSA
• Gentoo.org: Create a PKI Infrastructure Using the easy-rsa Tool

It may be costly to store certificate values in NVRAM, especially on models with limited NVRAM. The certificates consume about 14 KB of NVRAM space. If your model has limited NVRAM, consider storing certificates in JFFS or other router-connected mass storage. However, consider the security risks before following this procedure. Certificates may be accessible if you use Samba or NFS.

This shows how to include certificates in Custom Configuration if you don't want to use NVRAM:

#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

If you're using tls-crypt or tls-auth, you must also define a static pre-shared-key path/file.

A code commit was entered for Elliptical elliptic curve cryptography on 2024-10-19, and should be included in the next release. If your release doesn't support elliptical curve cryptography, you must configure Diffie-Hellman parameters.

Elliptic curve cryptography is also implemented in releases of OpenVPN since v2.4.

There are a few more settings you may need to configure, mostly outside OpenVPN. The most common issues relate to adjusting your OS to allow packet forwarding, and appropriately configuring the firewall.

Configuring a Linux-based firewall can be different from configuring one based on other *nix based OSes. In addition, several Linux distributions have their own tools to manage iptables. As a result, it's better to read the manuals for firewall configuration specific to your OS.

A common mistake when setting up a new Certificate Authority is to place all CA files on the OpenVPN server. **Avoid this**. A CA needs a private key to sign the certificates clients and servers use. If you lose control of the CA private key, you can no longer trust certificates from that CA. At that point, anyone with access to the key can sign new certificates without your knowledge. Clients using those certificates can then connect to your OpenVPN server without changing anything on the VPN Server. Whenever possible, place your CA files on an offline storage medium, only to be activated when you need to get a new certificate for a client or server.

There are 3 files you need to copy from a CA to achieve this:

1. A Private key (often a .key or .pem file)
2. A Certificate (often a .crt or .pem file), and;
3. A CA certificate (also a .crt or .pem file)

The server also needs a Diffie-Hellman parameters file.

Also, avoid generating keys on devices that don't have a good entropy source for randomizing data. This includes most common Wi-Fi routers and similar embedded devices. As well, many VMs don't have a good entropy source, or can be manipulated via the hypervisor. Always try to generate keys and Diffie-Hellman parameters on bare metal equipment.

To better understand PKI, see this introduction:
https://github.com/OpenVPN/easy-rsa/blob/master/doc/Intro-To-PKI.md

Within the CA, you can revoke certificates when needed. Using your preferred CA management tool, you can generate a Certificate Revocation List (CRL file). Adding this to the OpenVPN server should cause all client certificates to be checked against this list. Clients whose certificates are listed in the CRL won't be allowed to connect. This common method lets you deny access to a VPN on a per-user level.

Add this line to the OpenVPN server configuration:

   crl /full/path/to/crl.pem

In some cases, when you've generated server certificate/keys using EasyRSA 3, the server may not start. This can be happen when the server certificate requires a password but there was no way to provide it. In such cases, regenerate the certificate/key using the the EasyRSA “nopass” option. This should allow OpenVPN Server to start properly.

You must add network routes to access specific resources from other IP addresses via the VPN. A route tells your system where to send network traffic to access certain resources. An OS can handle multiple routes via multiple gateways at the same time.

For example, let's say:

• A server exists on 192.168.1.10 behind your VPN server.
• You want to access this server through the VPN.

You need to configure OpenVPN to route specific hosts or networks through the tunnel.

To do this, you must add a line similar to this in the server configuration:

   push "route 192.168.1.0 255.255.255.0"

You must then restart both the OpenVPN server and the client.

This will cause the server to tell any client that connects to route all traffic for IP addresses in scope 192.168.1.XXX through the VPN.

This example describes a basic setup. The setup is almost complete. The only thing left is to add the appropriate routes, as with normal routing.

You also must ensure return routes. Just because a VPN client can access a host behind the VPN server, doesn't mean the host behind the server will send the response via the same route. Hosts behind the VPN server must know which gateway to use for VPN traffic. Usually, this is done by adding a route on the existing default gateway. Then, if you run OpenVPN on an existing gateway, you have the return route already implicitly configured.

For a more detailed example, see the ​Using routing section in the Bridging and routing wiki page.

You can route all network traffic over the VPN. The configuration for this is fairly simple. However, you'll need to learn how to configure NAT on your VPN server for the virtual TUN adapter.

You can do this by pushing a “route everything over VPN” setting via the server. Another method is to add it explicitly to the client configuration. Don't use both methods at the same time.

This illustrates the server push method:

    push "redirect-gateway def1"

This illustrates the client configuration method:

    redirect-gateway def1

OpenVPN v2.3 and later support IPv6. Configuring IPv6 for a VPN is similar to the above IPv4 examples. To configure IPv6, you must use the
–server-ipv6 and –route-ipv6 options.

For example, adding this sets the IPv6 addresses for server/clients:

    server-ipv6 2001:db8:cada::/64

You can use the –route-ipv6 option two ways. You can push it from the server, or use it directly in client settings. The same is true for the –route option.

The syntax is similar:

    route-ipv6 2001:db8:daca::/64