Site Tools


OpenVPN Server

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

Basic tab

Start with WAN: Check this option if you need OpenVPN server to be available automatically each time the WAN interface comes up. This is suitable if OpenVPN server needs to be available 24/7.

Start Now: If the Start with WAN option is not checked, you'll need to click on the Start Now button if you want OpenVPN server to start immediately.

Interface Type

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

TUN, (short for “network TUNnel”), simulates a network layer device. TUN operates at OSI layer 3, and carries IP datagrams. TUN is used with routing. In general, TUN is used for VPN tunnels where only IP protocol is used.

TAP, (aka “network TAP”), simulates a link layer device, operating at layer 2. TAP carries Ethernet frames. TAP is used to create a network bridge.
Since TAP allows full Ethernet frames to pass through the tunnel, TAP also provides support for non-routable protocols like IPX and AppleTalk.

Other important differences include:

  • TAP has slightly more overhead, because it encapsulate the full Ethernet frame.
  • All devices connected to a TAP-based network form a single broadcast domain, since TAP acts as a bridge.

Since TUN is used with routing, it can help networks to intercommunicate, while stil remaining separate. Common applications of TUN/TAP include:

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

Advantages and Disadvantages

Some OpenVPN setups use only one virtual interface type. Others allow users to switch between adapter types. Therefore, it's important to understand the pros and cons of each adapter type.



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


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



  • 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.


  • All packets transported by TAP feature the overhead from Ethernet headers.
  • Tends to scale poorly.
  • For VPN tunnels, tends to cause more broadcast overhead.

The Interface type(s) must be identical on server and clients. You cannot use TAP on clients and TUN on servers or vice versa.

Bridge TAP with ...

This option becomes available if you selected the TAP Interface Type. This lets you select the VLAN to which you want to bridge the clients that connect to your OpenVPN server.


OpenVPN can run over either TCP or UDP transport protocols.

UDP OpenVPN Protocol

  • Faster speed - UDP is significantly faster than TCP.
  • Preferred connection for media streaming, VoIP and playing games online.
  • Lower reliability – Rarely, 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 strict corporate/government firewalls.
  • Slower speed – TCP's higher encryption tends to slow transfer rates compared to UDP.


This is the port on which the OpenVPN server will be listening on the WAN interface of your router. Make sure to configure firewall / IPTables rules to allow the traffic through this port. (Default: 443).


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

Authorization Mode

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

Here, select the authorization mode for the OpenVPN Server

  • TLS – OpenVPN will use Transport Layer Security authorization mode.
    The Certificates can be generated in the Keys section. You will need to
    configure the certificates in the KEYS tab.
  • Static Key – OpenVPN will use static key (pre‐shared) authorization mode.
  • Custom - The user will need to configure all 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


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


  • 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.

TLS Control channel security

This dropdown will automatically appear if you have selected TLS Authorization mode.

TLS requires a multi-packet exchange before it can authenticate a peer. During the exchange period, OpenVPN allocates memory and CPU resources to the potential peer. The potential peer exposes many parts of OpenVPN and the OpenSSL library to the packets it is sending. Most successful network attacks today seek to either exploit bugs in programs (such as buffer overflow attacks) or force a program to consume so many resources that it becomes unusable. The first line of defense is always good programming code. OpenVPN was written with buffer overflow attack prevention as a top priority. However, history has shown that many of the most widely used network applications ocasionally fall to buffer overflow attacks.

As a second line of defense, OpenVPN offers this special layer of authentication on top of the TLS control channel so that every packet on the control channel is authenticated by an HMAC signature and a unique ID for replay protection. This signature will also help protect against DoS (Denial of Service) attacks. An important rule of thumb in reducing vulnerability to DoS attacks is to minimize the amount of resources a potential, but as yet unauthenticated, client is able to consume.

Enabling this setting does this by signing every TLS control channel packet with an HMAC signature, including packets which are sent before the TLS level has had a chance to authenticate the peer. The result is that packets without the correct signature can be dropped immediately upon reception, before they have a chance to consume additional system resources such as by initiating a TLS handshake.

It should be emphasized that this feature is optional and that the key file used with –tls-auth gives a peer nothing more than the power to initiate a TLS handshake. It is not used to encrypt or authenticate any tunnel data.

Use Encrypt Channel instead if you want to use the key file to not only authenticate, but also encrypt the TLS control channel.

Auth Digest

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

Client Address Pool

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.

Advanced Tab

Poll Interval

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.

Direct clients to redirect Internet traffic

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.

Respond to DNS

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.

Cipher Negotiation

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 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

Negotiable ciphers

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:

Legacy/Fallback cipher

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.

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

TLS renegotiation time

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.

Manage Client-Specific Options

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.

Custom Configuration

You can specify the custom configuration to be used by OpenVPN server. Please refer to for further information about the parameters that can be used

Keys TAB

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:

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


Some warnings about certificates

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: ​

Adding certificate revocation lists

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

Routing notes

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 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"

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.

Routing everything over the VPN

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

What about IPv6?

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

Other aspects to consider when configuring a VPN

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.

openvpn_server.txt · Last modified: 2021/04/05 15:53 by hogwild