Vpn-server

OpenVPN Server

The OpenVPN Server menu allows you to view and configure settings for OpenVPN Servers within the web interface. A custom configuration window allows further customization of settings.

OpenVPN is an evolving VPN implementation that employs SSL/TLS security. It has many configuration options. OpenVPN is quite forgiving and strives to maintain backwards compatibility between versions. However, there are still interoperability and other functional differences between versions. For example, clients and servers may be configured on different versions. Encryption algorithms may be negotiated differently, and so on. Tomato64 2023.2 includes OpenVPN 2.6.1.

For detailed information, refer to the OpenVPN documentation and support forums here:
https://build.openvpn.net/man/openvpn-2.5/openvpn.8.html

OpenVPN can concurrently run two server instances of different configurations ("Server 1" and "Server 2"). Each server menu has a set of tabs: "Basic", "Advanced", "Keys" and "Status".

The "Basic" and "Advanced" tabs are used to configure the general setup of the servers, and to set OpenVPN configuration file "option" entries. Option settings are read by the OpenVPN server when it starts. The options set in the web interface are read first, followed by any custom options.

The "Keys" tab allows you to define various encryption keys to be used. It also allows keys to be generated directly within Tomato64, if they are not sourced externally.

When the server is running, the "Status" tab provides an overview of connected clients, routing and statistics.

Basic Tab

0d9ebf393ef53801e53584bcb1d4fc72.png

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, or the server is not running, clicking this makes the OpenVPN server start immediately.

Interface Type

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. Some clients do not support TAP.

Bridge TAP with ...

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

Protocol

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.

Port

This sets the port on which the OpenVPN server listens on the router's WAN interface. Make sure to configure firewall / IPTables rules to allow the traffic through this port. 1194 is the official IANA port number assignment for OpenVPN but other port numbers may be used.

Firewall

• Auto — Tomato64 creates all firewall / NAT rules required for the tunnel.
• Custom — Tomato64 configures no firewall / NAT rules. The Administrator
  

must create them manually.

• 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. 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 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 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 uses 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.
Static Keys have security limitations. While easier to set up than an X.509 PKI,
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. Just one client, and one server.
• 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.

TLS Control Channel Security

(tls-auth/tls-crypt)

This menu appears automatically if TLS Authorization mode is selected and allows a choice of security measures to be applied to the control channnel.

The TLS authentication and encryption options require the generation and (secure) distribution of various additional static keys for the server and client/s. At least one Pre-Shared-Key is required with the same key used by the server and client/s, for tls-auth and tls-crypt, whereas tls-crypt-v2 requires client-specific keys to be generated. (Ref. OpenVPN --tls-auth, --tls-crypt, --tls-crypt-v2 and --secret).

• Disabled — No additional TLS authentication or encryption is applied.

• Bi-directional Auth — (tls-auth) [Direction] is set to 2.
  

The HMAC-send and cipher-encrypt keys will be used.

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

The HMAC-send HMAC keys will be used.

• Encrypt Channel — (tls-crypt) [Direction] is set to 3.
  

The HMAC-send, cipher-encrypt, and HMAC-receive keys will be used.

• Encrypt Channel v2 — (tls-crypt-v2[Direction] is set to 4.
  

HMAC-send, cipher-encrypt, HMAC-receive and cipher-receive are 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 defense is good programming. One main goal when coding OpenVPN was to prevent buffer overflow attacks. However, many widely-used network applications still occasionally fall to buffer overflow attacks.

OpenVPN's second line of defense is an authentication layer on top of the TLS Control channel (tls-auth). At this layer, every packet on the control channel is authenticated by an HMAC signature and a Unique ID. This authentication layer 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, DoS attacks are less likely.

Enabling TLS Control Channel Security (Encrypt Channel / tls-crypt) makes Tomato64 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. As a result, 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.

Auth Digest

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

VPN Subnet/Netmask

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.

When TUN is selected Tomato64 sets the VPN topology to "subnet". This mode allocates a single IP address per connecting client from the subnet range. If another OpenVPN topology is required then this must be set in custom configuration. Ref. OpenVPN option "--topology". (Successful overriding of "--topology subnet" with a different topology in custom configuration to be confirmed.)

Client Address Pool

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.

Advanced Tab

openvpn_server_configuration-advanced_tab-3.jpg

Poll Interval

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.

Push LANx (brx) to clients

[TBD]

Direct clients to redirect Internet traffic

If enabled, 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 will perform its default routing.

Respond to DNS

On supported platforms, this sets the DNS server address the client uses to the local Tomato64 DNS. (Ref.OpenVPN "--dhcp-option")

Data Ciphers

This field contains a colon-delimited list of ciphers in the order in which they are to be negotiated with the clients. If nothing is defined, the server defaults to "AES-256-GCM:AES-128-GCM".

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

Available ciphers include:

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

(Ref. OpenVPN "--data-ciphers")

Compression

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

Combining compression and encryption is tricky. 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.

TLS Renegotiation Time

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 asked 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 to set this parameter to a higher value on either the client or server, while the other end 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" (disabled) on one side of the connection, and to your preferred value on the other side.

Manage Client-Specific Options

This enables individual client options to be applied. If this is disabled, the option to allow client certificates with the same common name is applied. (Ref.OpenVPN "--duplicate-cn")

If this option is selected, further options appear in the Web interface which enable configuration of client-to-client access.

The client-to-client option enables an OpenVPN client to access the other's, and/or the network behind each OpenVPN client. OpenVPN blocks network access between OpenVPN clients unless you enable the client-to-client option.

When you enable Client <-> Client access on the server, you can limit the networks accessible to your clients. Use the table "Allow Only These Clients" in order to specify and limit the access your client will have over your network.

(Ref. OpenVPN "--client-to-client")

Using Client-specific options requires each client to have a certificate with a unique common name, because it's used to identify which client rule to apply, and by default, duplicate CNs are rejected.

If you still need client-specific options and don`t want to use unique client certificates, you'll need to allow usernames as common name, or duplicate common names. However, these may not lead to the desired result if you are expecting expect different client rules.

Consider using either of these phrases in your Custom Settings:

duplicate-cn

Or:

username-as-common-name

The push checkbox on the clients table can be used to push routes to clients. If you leave it unchecked, routes should be set separately in each client configuration. This check box is not applicable if the Client <-> Client feature is disabled.

Other client-specific options are possible using custom configuration and a Client Configuration Directory. Enabling client-specific options creates an internal Client Configuration Directory (Ref. OpenVPN "--client-config-dir") in which to hold client specific options configured in the GUI. If you define additional or different client-specific options, not available in the Web interface, then a custom "client-config-dir" option can be set in the custom configuration. Required client-specific options can then be placed there.

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

Custom Configuration

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

For details about custom parameters that can be used, please see:
https://build.openvpn.net/man/openvpn-2.5/openvpn.8.html
.

Keys Tab

If you chose TLS authorization mode, you MUST configure the certificates.

Instead of using a static key, you can let the machines 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.

For a TLS handshake to occur, both "server" and "client" must have their respective digital certificates. Also, Diffie-Hellman parameters need to be generated for the "server" which will finally lead to creation of a shared secret number. You will generate your own certificates. Every digital certificate is issued by a Certificate Authority, ("CA"), so you will first create a CA. The tools to create a Certificate Authority, certificates, and Diffie-Hellman parameters are provided by OpenVPN and are all available within Tomato64.

The first step in building an OpenVPN 2.x configuration is to establish a Public Key Infrastructure (or "PKI"). The PKI consists of:

• A separate certificate (public key) and private key for the server
  

and for each client

• A master Certificate Authority (CA) certificate and key used to sign
  

each of the server and client certificates

OpenVPN supports bidirectional, certificate-based authentication. Client and server must authenticate each other's certificate before they establish mutual trust.

Both server and client will authenticate the other, first, by verifying the certificate presented was signed by the master certificate authority (CA). Then, they will test the information in the authenticated certificate header. That information includes the certificate common name (CN) or certificate type (client or server).

This security model has a number of desirable features for a VPN:

• The server only needs its own certificate/key. It doesn’t need to know
  

the certificate 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).
  

Because the server can verify this signature without needing access
to the CA private key itself, the CA key can be stored 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). 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 fields
  

embedded in the certificates, such as the Common Name.

Note that server and client clocks need to be roughly synchronized, or certificates might not function properly.

The user has the option to generate ALL required keys directly from Tomato64 GUI using the Generate Keys button** **or simply using the easy-rsa tool provided by OpenVPN software and following these instructions:

• 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|https://wiki.gentoo.org/wiki/Create_a_Public_Key_Infrastructure_Using_the_easy-rsa_Scripts#Create_CA_certificate]

Please be aware that using NVRAM space to store certificate values may be expensive, especially for routers with limited RAM. The certificates consume about 14 KB of NVRAM space. Therefore, if your router has limited NVRAM available, it might be a good idea to store the certificates in JFFS or other mass storage attached to your router. However, **Please consider the security risks before following this procedure. **Certificates may be accessible if you enable Samba or NFS filesharing.

Here's an example of how to include 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

Additionally, you must define a static pre-shared-key path/file if you are using tls-crypt or tls-auth.

Note that because Tomato64 does not use TLS with elliptic curve cryptography, you **must **configure the Diffie-Hellman parameters.

OpenVPN Server Notes and Troubleshooting

There are a few more things which may need to be configured, mostly outside of OpenVPN. The most common issues relate to adjusting your operating system to allow forwarding of packets, and configuring the firewall properly.

Configuring a Linux-based firewall can be quite different from configuring one based on other Unix based operating systems. In addition, several Linux distributions have their own tools to manage iptables. Therefore, it is better to read the specific manuals for firewall configuration on your operating system.

A Warning about Certificates

A common mistake when setting up a new Certificate Authority is to place all CA files on the OpenVPN server.%% Avoid doing this. %%A CA requires a private key to sign the certificates used by clients and servers. If you lose control of the CA private key, you can no longer trust certificates from that CA. Anyone with access to the CA private key can sign new certificates without your knowledge, and clients using those certificates can then connect to your OpenVPN server without modifying 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 just 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 which do not have a good entropy source for random data. This includes most common Wi-Fi routers and similar embedded devices. Also, in many cases, virtual machines don't have a good entropy source, or can be manipulated by the hypervisor. Always try to generate keys and Diffie-Hellman parameters on bare metal equipment.

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

Adding Certificate Revocation Lists

Within the CA, you can also revoke certificates as needed. Using your preferred CA management tool, you should be able to generate a Certificate Revocation List (CRL file). Adding this to the OpenVPN server should cause all client certificates to 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 fromk other IP addresses through the VPN tunnel, you need to add network routes. A route tells your system where it needs to send network traffic in order 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.

To configure this, you need to add a line in the server configuration and restart OpenVPN server and OpenVPN client.

   push "route 192.168.1.0 255.255.255.0"

Now, when the client 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 an example of 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.

Remember that you also need to consider "return routes". Just because your VPN client can access a host behind your VPN server, doesn't mean that the host behind the VPN server can/will send the response via the same route. Therefore, you must ensure the hosts behind your VPN server also knows which gateway to use for your VPN. This is most commonly fixed by adding a route on your existing default gateway. That way, if you run OpenVPN on an existing gateway, you have the return route already (implicitly) configured.

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

Routing all Traffic over the VPN

It is possible to route all network traffic over the VPN. The OpenVPN configuration for this is fairly simple. However, youll need to investigate how to configure NAT on your VPN server for the virtual tun adapter.

You can either push a "route everything over VPN" setting 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

About IPv6

OpenVPN v2.3 and later support IPv6. Setting up IPv6 in the tunnel is roughly similar to the IPv4 examples above. 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 by pushing it from the server, or using it directly in the client configuration. The same is true for the –route option. The syntax is similar too:

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