Tunnel Settings

The tunnel settings section governs how traffic flows between the server and clients, including routing and compression.

IPv4/IPv6 Tunnel Network

These are the subnets used by the VPN. The exact usage depends on the mode and size of the subnet. The firewall uses these addresses for direct communication between tunnel endpoints even when connecting two existing remote networks. The value must be an unused, non-overlapping subnet. It must not be in use locally or at any remote site. One or both of IPv4 Tunnel Network and IPv6 Tunnel Network may be entered, or in the case of a tap bridge, neither.

For SSL/TLS modes with subnets large enough for multiple clients (e.g. IPv4 Tunnel Network is larger than /30), OpenVPN uses a client/server mode. In this situation, these values are the pools of addresses the OpenVPN server assigns to clients. The server end of the OpenVPN configuration will use the first address in this pool for itself, and assign additional addresses to connected clients as needed. The specific method of assignment varies based on the chosen value for Topology. In OpenVPN client/server mode the server can push settings to clients, and client-specific overrides can influence how clients behave. For site-to-site VPNs in this mode, an override must contain IPv4/6 Remote Network/s values which route subnets to specific clients (iroute).

For a site-to-site SSL/TLS server using IPv4 and an IPv4 Tunnel Network value of x.x.x.x/30, or a shared key server, OpenVPN uses peer-to-peer mode. In peer-to-peer mode, each server can only have one client. In this mode, clients do not require client-specific overrides or iroutes configuration, however, the server also cannot push routes or settings to the client.

Warning

These specific types of peer-to-peer modes are not compatible with OpenVPN Data Channel Offload (DCO).

This field also accepts the name of a network type alias but it must only contain a single entry.

See also

See OpenVPN Site-to-Site Configuration Example with SSL/TLS for more information on a site-to-multi-site example using a large tunnel network and iroutes.

Bridging Options

When using tap mode for a remote access SSL/TLS VPN, the GUI offers additional options to control bridging behavior in OpenVPN and client address assignment.

See also

Bridging OpenVPN Connections to Local Networks

Bridge DHCP:

When selected, OpenVPN passes through DHCP to the bridged. In the most common scenario, this is LAN.

Using this method connecting clients receive IP addresses from the same DHCP pool used by clients on the LAN.

Bridge Interface:

This setting indicates to OpenVPN which interface will be used for the bridge. In most cases this is LAN.

Warning

This does not create a bridge in the operating system, that must be done separately.

This option controls which existing IP address and subnet mask are used by OpenVPN for the bridge. Setting this to none will cause the Server Bridge DHCP settings below to be ignored.

Bridge Route Gateway:

Makes OpenVPN push the Bridge Interface IPv4 address to connecting clients as a route gateway.

When the IPv4 Tunnel Network in OpenVPN is empty for a bridged VPN, connecting clients cannot automatically determine a server-side gateway for use with routes pushed to clients by the server.

Server Bridge DHCP Start/End:

Defines a DHCP range from which OpenVPN can assign addresses to clients. If these settings are left blank, OpenVPN passes DHCP through to the bridge interface and it ignores the interface setting above.

When set, this range should be within the same subnet as the Bridge Interface but it should not overlap an existing in-use portion of the subnet, such as the current DHCP pool.

This allows a range of IP addresses to be set aside for use only by OpenVPN clients so they may be contained within a portion of the internal network rather than consuming IP addresses from the existing DHCP pool.

Redirect IPv4/IPv6 Gateway

When a Redirect IPv4/IPv6 Gateway option is selected the server pushes a message to clients instructing them to forward all traffic for that address family, including Internet traffic, over the VPN tunnel.

This option only works in SSL/TLS client/server modes (tunnel network larger than /30).

IPv4/IPv6 Local network(s)

These fields specify local networks reachable by VPN clients, if any. Entries must be in CIDR or prefix format (e.g. 192.168.56.0/24) and they can be a host or network type alias name. The server pushes a route for these networks to clients when they connect.

To specify multiple subnets of a particular address family, enter the subnets separated by a comma, e.g. 192.168.2.0/24, 192.168.56.0/24 or use an alias.

This function relies upon the ability to push routes to the client. For IPv4 it is only valid in SSL/TLS client/server mode with a tunnel network larger than /30. It will always work for IPv6 provided the VPN does not use a similar too-small prefix.

Warning

If the server does not push any routes, clients will not receive a remote gateway value, which they may require. For example, pfSense® software will use the remote gateway value when creating a gateway for gateway monitoring and policy routing. If the server does not need to push any routes to the client, use a custom option to push the gateway value to clients, for example: remote-gateway x.x.x.1; where the IP address is the IP address of the tunnel on the server.

IPv4/IPv6 Remote Network

This option only appears for Peer-to-Peer type connection and it is not available for remote access servers.

OpenVPN adds operating system route table entries for the specified subnets which hand the traffic over to this OpenVPN instance for processing. Entries must be in CIDR or prefix format (e.g. 192.168.56.0/24) and they can be a host or network type alias name.

To specify multiple subnets of a particular address family, enter the subnets separated by a comma, e.g. 192.168.2.0/24, 192.168.56.0/24 or use an alias.

For Peer-to-peer SSL/TLS servers in client/server mode (tunnel network larger than /30), each network listed in this field must also be present in a client specific override as a remote network entry for a client. Without that entry, OpenVPN has no way to determine which client should receive traffic for a network. The remote networks listed here in the server configuration inform the operating system routing table to deliver the traffic to OpenVPN, while the entries in an override associate networks with specific remote clients.

Shared key and SSL/TLS servers in peer-to-peer mode (/30 tunnel network) do not need overrides as there can only be a single client per server.

Concurrent Connections

Specifies the number of clients that may be simultaneously connected to this OpenVPN server instance at any given time.

Warning

This is a collective limit for all connected clients, not a per-user setting.

Compression

Warning

Compression for encrypted traffic is dangerous and should be disabled when possible!

The OpenVPN project has deprecated compression support and they will remove it from future versions.

Read the text in this section carefully! Compression can potentially increase throughput but may allow an attacker to extract secrets if they can control compressed plain text traversing the VPN (e.g. HTTP). Before enabling compression, consult information about the VORACLE, CRIME, TIME, and BREACH attacks against TLS to decide if the use case for this specific VPN is vulnerable to attack.

When compression is enabled OpenVPN attempts to compress traffic crossing VPN before it performs encryption. This has a potential to save bandwidth usage for some traffic at the expense of decreased security and increased CPU utilization on both the server and client.

For high speed connections such as the usage of OpenVPN across a LAN, high speed low/latency WAN, or local wireless network, compression adds unnecessary overhead as the delay added by the compression may be more than the delay saved in transmitting the traffic.

If nearly all of the traffic crossing the OpenVPN connection is already encrypted (such as SSH, SCP, HTTPS, among many other protocols), do not enable LZO compression because encrypted data is not compressible and the LZO compression will cause slightly more data to be transferred than would be without compression. The same is true if the VPN traffic is almost entirely data that is already compressed.

Allow Compression:

Controls whether or not compression is allowed on the VPN, and how it is handled.

Decompress incoming, do not compress outgoing:

Asymmetric compression support. Accepts compressed packets from the remote peer but will not perform any compression on outgoing packets. This behavior allows for a smoother transition when peers use older versions of OpenVPN.

Refuse any non-stub compression:

When set, OpenVPN will refuse any attempt to compress packets. Compressed packets from peers are dropped.

Compress packets:

When set, OpenVPN allows compression and both accepts compressed packets from peers and also compresses packets before sending them to peers.

Compression:

This selector controls the handling of LZO compression for this OpenVPN instance when the settings allow compression. There are several possible settings each with slightly different behavior.

Disable Compression:

Omits compression directives from the OpenVPN configuration entirely. OpenVPN will not perform compression, but other methods such as Client-Specific overrides or advanced options may override this behavior.

Disable Compression, retain compression packet framing:

OpenVPN will not perform compression, but keeps the packet framing for compression. This allows compression to be changed later, for example by pushed settings. When set this way, OpenVPN will advertise support for LZ4 and LZO compression to peers using IV_ variables. Always adds one extra framing byte to packets for compression.

Enable Compression (stub):

Similar to the previous setting, but it does not advertise compression support to peers.

Enable Compression (stub v2):

Similar to the previous setting but it utilizes a better framing that does not increase packet overhead when it cannot compress a packet.

LZ4 Compression:

A newer compression algorithm offering best compression performance and lowest CPU consumption. May not be supported by older clients.

LZ4 Compression v2:

The same as LZ4 compression but it utilizes a better framing that does not increase packet overhead when it cannot compress a packet.

LZO Compression:

An older compression algorithm with wider support, especially from older clients.

Omit Preference + Disable Adaptive LZO Compression:

Does not specify a compression directive in the OpenVPN configuration and also explicitly disables adaptive compression.

Adaptive LZO Compression:

OpenVPN will periodically check the efficiency of data compression for VPN traffic and disable compression if it is performing poorly. This prevents OpenVPN from compressing already compressed or encrypted data.

LZO Compression (Legacy Style):

Enables LZO compression using the deprecated comp-lzo yes directive. This can help interoperation with older legacy clients which cannot be updated. When present in the configuration, the server can push a different value to clients as needed.

No LZO Compression (Legacy Style):

Disables LZO compression using the deprecated comp-lzo no directive. This can help interoperation with older legacy clients which cannot be updated. When present in the configuration, the server can push a different value to clients as needed.

Push Compression:

When set, OpenVPN will push the selected compression settings to connecting clients.

Type-of-Service

When this option is enabled OpenVPN sets the Type-of-Service (TOS) IP header value of tunnel packets to match the encapsulated packet value. This may cause important traffic to be handled faster over the tunnel by intermediate hops at the cost of minor information disclosure.

The most common example is VoIP or video traffic. If the TOS bit is set to reflect the priority of the traffic it can help QoS along the path, but someone intercepting the traffic could see the TOS bit and gain some knowledge about the contents of the traffic inside the tunnel. For those who rely on TOS bits for QoS, the benefit may outweigh the information leak.

Inter-Client Communication

This option controls whether or not connected clients are able to communicate with one another. To allow this behavior, check the option. When unchecked, clients can only send traffic to the server or destinations beyond the server such as routed networks or the Internet.

Typically in remote access style deployments it is unnecessary for clients to reach each other, but there are use cases when it can be helpful. One example is remote web developers working together and running test servers on their local workstations. With this option activated, the developers can reach the other self-hosted test servers for collaborative development.

Duplicate Connections

Controls whether or not OpenVPN will allow multiple connections from the same user to work simultaneously.

This is primarily for security reasons so the same certificate cannot be used by multiple people or devices simultaneously. The best practice is to use a unique certificate for each connecting device, or at least for each user. Otherwise, if a client is compromised there is no way to revoke that one client alone; certificates must be reissued to all clients that share the same certificate.

By default OpenVPN will associate an IP address from its tunnel network with a specific certificate or username for a given session. If the same certificate connects again, the server assigns it the same IP address and will either disconnect the first client or cause an IP conflict where neither client will receive proper data.

If a setup that uses the same certificate in multiple locations is an absolute requirement and cannot be avoided, check Duplicate Connections to allow the non-standard behavior of multiple clients using the same certificate or username.

Duplicate Connection Limit

When active, the server will limit the number of simultaneous connections from the same client. New connections from the same client that exceed this limit will be denied by the server. To free up unused sessions and allow new connections from the same client more quickly, set lower values for Ping settings.

Note

Due to unstable connectivity in practice, clients may sometimes initially create multiple sessions on the server when establishing the tunnel. These extra temporary sessions will count towards the limit until they time out.