- Client automatic failover (approximately 13 seconds after server failure)
- Replicated servers
- Client to client traffic across replicated servers
- Static client IP addresses
- NAT and non-NAT routing configurations
- All secondary authentication methods
- Client port forwarding
- Client DNS mapping
- Automatic client DNS configuration
- Routed client network links also know as an iroute
- IPv6 support
- Client access to linked servers (site-to-site link connections will continue to use OpenVPN)
WireGuard authentication in Pritunl utilizes keys already in the client profile. This allows transitioning to WireGuard without requiring users to re-import their profile. Many administrators do not configure a valid HTTPS certificate and HTTPS is not relied on or required to provide secure authentication. Authentication is done with three keys providing multiple layers of encryption and authorization.
Client SHA512-HMAC Key (Authorization)
The client will use a SHA512-HMAC secret to sign each connection request. The server will also use this secret to sign the response allowing the client to verify the connection response. This is the same authentication system used to authorize the client configuration sync which syncs profile configuration changes such as host addresses and server port changes (private keys are never synced).
Client/Server NaCl Asymmetric Key (Authorization + Encryption)
The client utilizes a NaCl public key for the server that is included in the client profile. This provides asymmetric encryption of the connection request from the client to the server. The server will encrypt the response with the clients NaCl public key providing encryption of the response. The client will also verify the server response using the server NaCl public key. This is the same authentication system used to provide the additional layer of encryption and authorization available in OpenVPN connections with passwords and two-factor codes.
Client RSA-4096 Asymmetric Key (Authorization)
The clients RSA certificate and key is used to sign each connection request. The server will use this verify the client connection request. This is the same certificate used to verify OpenVPN connections.
Each WireGuard connection uses a new WireGuard key. This is done to provide the highest level of security but it will delay network connectivity when the user returns to a computer that has been asleep. The WireGuard private key is stored in the memory of the Pritunl client background service and also in the WireGuard configuration file. WireGuard uses a connection-less design and this private key could be used by an attacker to hijack the connection even if multi-factor authentication is used. In high security environments it is important to consider that OpenVPN connections with multi-factor authentication will not have these weaknesses. For this reason the server will quickly revoke WireGuard keys of inactive clients to limit the possibility of this occurring. The server will also validate that keys are not reused.
Once the client has connected it will send a ping request to the server every 10 seconds. This request allows the client to quickly detect a down link and failover in approximately 13 seconds. If the server does not receive a ping request in 6 minutes it will disconnect the user and revoke the public key.
To allow WireGuard connections the DKMS modules must be separately installed. This can be done on RHEL7 using the commands below. If
sudo dkms status does not show the module with the current kernel version restart the server and run
sudo dkms autoinstall.
sudo curl -o /etc/yum.repos.d/jdoss-wireguard-epel-7.repo https://copr.fedorainfracloud.org/coprs/jdoss/wireguard/repo/epel-7/jdoss-wireguard-epel-7.repo sudo yum -y install kernel-devel kernel-uek-devel wireguard-dkms wireguard-tools sudo dkms autoinstall sudo dkms status sudo reboot
In the server settings enable WireGuard. Configure the Virtual WG Network with a network that has the same CIDR as the VIrtual Network. Then configure the WG Port to select the UDP port for WireGuard connections.
Clients will have the same static address from the Virtual Network on the Virtual WG Network.
The clients must also be configured using the WireGuard Client documentation.
Updated about a year ago