Endpoint Configuration

Protocol

The IP protocol clients will use to connect to this VPN.

UDP on IPv4/IPv6 only:

UDP is the most reliable and fastest choice for running OpenVPN, and the best practice is to always use UDP when possible.

Connectionless protocols such as UDP are always the best practice to use when tunneling traffic.

This mode binds to a single interface and limits OpenVPN to only accepting IPv4 or IPv6 exclusively, not both at the same time.

TCP on IPv4/IPv6 only:

Using TCP for a VPN is slower and can be more problematic. In some rare cases TCP can be work around limitations of a client environment, such as bypassing firewalls by running an OpenVPN server on TCP port 443.

TCP is connection oriented with guaranteed delivery, which means any lost packets are retransmitted. This sounds like a good idea on the surface but TCP retransmissions will cause performance to degrade significantly on heavily loaded Internet connections or those with consistent packet loss.

TCP traffic frequently exists within tunnels and it is undesirable to retransmit lost packets of encapsulated VPN traffic. In cases where TCP is wrapped around TCP, such as a VPN tunnel using TCP as a transport protocol, when a packet is lost both the outer and inner lost TCP packets will be re-transmitted. Infrequent occurrences of this will be unnoticeable but recurring loss will cause significantly lower performance than UDP. If the traffic inside the tunnel requires reliable delivery, it will be using a protocol such as TCP which ensures that and will handle its own retransmissions.

This mode binds to a single interface and limits OpenVPN to only accepting IPv4 or IPv6 exclusively, not both at the same time.

Warning

TCP mode is not compatible with DCO.

UDP on IPv4 and IPv6 on all interfaces (multihome):

This option binds to all interfaces using UDP for both IPv4 and IPv6. This mode allows OpenVPN to track incoming connections and respond back to clients using whichever IP address they used when connecting to the VPN. This works ideally with multiple WAN connections.

Since this mode can also work with both IPv4 and IPv6, clients of both types can be served by a single instance.

The primary downside of this mode is that since it binds to all interfaces, the port this instance uses cannot be used by any other service on the firewall. Also, since it does not bind specifically to a specific interface, return routing can be problematic in certain scenarios. Furthermore, outgoing connections will follow the routing table and cannot use specific interface addresses.

TCP on IPv4 and IPv6 on all interfaces (multihome):

Similar to the above, but using TCP instead of UDP.

Interface

Selects the interface, VIP, or failover group that the OpenVPN instance will use when communicating with peers. This also controls which interface the traffic from the instance will exit.

Note

The GUI hides this option if the Protocol is set to a multihome selection.

Several types of options are listed in the drop-down for Interface, and some have special behavior or use cases:

Interfaces:

OpenVPN will bind to the interface address. If the interface is dynamic, such as DHCP, OpenVPN will automatically bind to the new address when it changes.

VIPs:

OpenVPN will bind only to the specified VIP, which must be an IP alias or CARP type VIP.

Gateway Groups:

For use with failover gateway groups. OpenVPN will bind to the address of the interface which contains the currently active gateway in the group. If that gateway becomes unreachable, it binds to the next one instead, and so on.

Localhost:

Useful for multi-WAN deployments. Binding to localhost and utilizing port forwards to accept connections from several interfaces and/or ports is a versatile way to provide redundant OpenVPN connectivity for connecting clients.

Any:

Binds to every address on every interface. Though tempting, this option is not recommended. When used with UDP, replies to Internet clients will always exit back out the default gateway WAN, which may be undesirable. If a use case calls for this type of behavior, consider selecting one of the Protocol options which uses multihome instead.

Local port

The port number upon which OpenVPN will listen for incoming connections from peers. Firewall rules must allow traffic to this port and this port must be specified in the client configuration.

The port for each server must be unique for each interface when using a standard UDP or TCP Protocol choice and must be globally unique if using a multihome Protocol.