Link Configuration

Links allow creating site-to-site links with IPsec using Pritunl Link clients. The Pritunl Link client communicates with the Pritunl cluster using HTTPS. This allows linking sites without needing to provide database access. Multiple link clients can be deployed to each site for automatic failover. Automatic routing table support is available on AWS, Google Cloud and Ubiquiti Unifi. The diagram below shows the infrastructure design of Pritunl IPsec links.

The Pritunl server does not provided site-to-site connectivity in a Pritunl Link configuration. The Pritunl server will only manage the link state for Pritunl Link clients connected to the Pritunl server. Each link must have at least two locations and each location must have at least one host. Pritunl Link cannot run on the same host as the Pritunl server.

Creating a Link

Create the link and locations for each network, the example below has two VPCs. Add a route for each subnet on the network. Create a host for each Pritunl link client, two link clients can not use the same host. The hosts will be associated with a Pritunl Link client using the URI.

The link hosts are defined in the Pritunl web server first then associated with a pritunl-link client using the URI. Click Add Host to add a new host then associate that host to a pritunl-link client configured using the other tutorials for each cloud provider.

The pritunl-link client cannot run on a Pritunl server and the Pritunl server will not function as a link host. All hosts must be defined in the link configuration.

Once the links are configured the state will change to Available when the host is connected to the Pritunl cluster and Active when the host is being used for an IPsec connection.

Recommended IPsec Ciphers

If all sites are using the latest version of pritunl-link it's recommended to use the aes128-sha256-x25519 IKE cipher and aes128gcm128-x25519 ESP cipher. The Force Preferred Cipher can also be used to require IPsec links to use this cipher to prevent automatic cipher selection from selecting a slower cipher.

Below is a list of common ciphers, a full list is available in the strongSwan Wiki. AES 128 GCM is the recommended cipher for the best performance

# AES 128 GCM
IKE=aes128-sha256-x25519 ESP=aes128gcm128-x25519

# AES 256 GCM
IKE=aes256-sha256-x25519 ESP=aes256gcm128-x25519

# ChaChaPoly
IKE=chacha20poly1305-prfsha256-x25519 ESP=chacha20poly1305-x25519

These newer GCM ciphers provide high link speeds with minimal CPU usage. High end network adapters such as the Mellanox ConnectX-6 DX also support offloading this cipher. Below is a speed test on an Oracle Cloud BM.Optimized3.36 bare metal server with Mellanox ConnectX-6 DX adapters. The single connection test measured 12.8 gigabit/sec and the 10 connection test measured a total speed of 13.2 gigabit/sec

Host Checking

Host checking uses an additional network check between all hosts in a link. These checks are used to detect network partitions and discover the best link to activate in a high availability configuration. All link clients must be updated to v1.2 to support host checking.

The client must have access to TCP port 9790 on all other hosts.

Backoff Timeout

The Backoff Timeout option in the host settings allows setting a duration in seconds that the host will be ineligible for becoming an active host. This timer will begin after a host goes offline, once the configured number of seconds has past since the host went offline the host can be selected as a primary.

Route Removal

By default the link client will not attempt to remove any routes from routing tables. This is done to prevent potentially removing a route that was manually modified by an administrator. For larger more complex configurations automatic removal of unused routes can be important. To enable this run sudo pritunl-link remove-routes-on on all link clients. If a route is removed in the Pritunl link configuration the link clients will remove that route from the routing tables.

Automatic Firewall

The link automatic firewall will configure iptables to only allow other link hosts to access ports UDP/500, UDP/4500 and TCP/9790. The link will automatically adjust the allowed IP addresses when hosts are added or removed or when a host IP address changes. This allows configuring the instance/external firewall to allow all IP addresses to access these ports without reducing the security of the system. This option is useful for configurations where a host IP address can change frequently. Any application that interferes with iptables such as firewalld cannot be used with this option. This option is not intended to replace an instance/external firewall, it will only control access to the ports used by pritunl-link. Run the command sudo pritunl-link firewall-on on the link host to enable the firewall.

When enabling this option all external firewalls such as the instance or VCN firewall should allow ports UDP/500, UDP/4500 and TCP/9790 from 0.0.0.0/0. The pritunl-link client will handle further restricting the access to these ports from the Linux system firewall.

Host Priority

Each host has a priority that defaults to 1. The host with the highest priority that is available will always be used. This allows using a more powerful server as the primary and a less powerful server for failover to reduce costs. It is also necessary for some use cases such as the one shown below. In the example below the unifi-office location has a primary and failover client in both us-east-office and us-west-office. This configuration is useful if the unifi-office location needs access to both aws-us-east and aws-us-west but aws-us-east can not access aws-us-west. Port forwarding is needed for the clients in the unifi-office location because the clients are behind a Unifi Security Gateway with only one public IP address. Without setting a priority it would be possible for both link0 and link1 to become active at the same time. If this were to happen both clients would continue to update the port forwarding preventing the other client from connecting. To solve this link0 in unifi-office should be given a higher priority then link1 in both us-east-office and us-west-office. This will ensure the same link client is active between us-east-office and us-west-office while still having fast and automatic failover to link1 if link0 were to fail.

Host Timeout

Each host has a optional timeout, this will override the default timeout of 30 seconds. The time to failover is around 3 seconds + timeout. A longer timeout will increase the time to failover when a link host goes offline. Depending on how the link host is lost it may send a signal to the Pritunl server to indicate it is offline which will allow the link to failover in 3 seconds. Setting a lower timeout can shorten the time to failover but can also lead to an unnecessary downtime and failover in the event of a short latency spike or connectivity issue.

IPsec Routers

When running pritunl-link on a network with an IPsec router only one host can be used. Automatic failure for that network will not be available but other link locations can use automatic failover. After configuring all link locations use the list of routes in /var/lib/pritunl_link/routes to then create static routes. Add a static route on the local network router for each of the subnets with the next-hop set to the local IP of the server running pritunl-link. If new link locations or routes are added this file will update and the static routes will also need to be updated.

Extensive testing with different routers and cloud provider IPsec offerings has shown that these router IPsec clients will significantly underperform an instance or server running IPsec. This includes cloud IPsec offerings that are managed by the cloud provider. Running IPsec on a router should only be done when it is not possible to configure a pritunl-link client with port forwarding. Additionally many failover features will be unsupported when not using pritunl-link clients for IPsec.

Connectivity Issues

Connectivity issues are often caused by incorrectly configured firewalls. In the example below client1 is making a SSH connection to server1. For this connection server1 must allow ssh traffic from the IP address of client1. This connection will also require that pritunl-link accept ssh traffic from client1. The ssh connection going to server1 will still be detected as ingress traffic to pritunl-link requiring that both pritunl-link and server1 allow the traffic from client1. To avoid this typically pritunl-link should accept all traffic from the VPC network with client1.

(client1 ssh client) -> (pritunl-link) -> (server1 ssh server)