Hi team.
I am using Pritunl Enterprise and connecting the servers to the Pritunl VPN using a Wireguard connection. And as luck would have it, the Wireguard key expires at inopportune moments (for example, when I restore a database from a backup via VPN)
I looked through all Wireguard settings in the Pritunl Web UI and couldn’t find a setting for the public key lifetime for Wiregurad.
Would it make sense to add settings for wireguard in the Web interface?
Can I turn off the lifetime for the Wireguard public key altogether?
I found in configuration file parameter ‘wg_public_key_ttl’: 604800
And sometimes Pritunl will update the key in less than the specified time. Can you tell me why?
Correct me if I’m wrong, but I read that there is some kind of limit on the number of files that can be transferred via Wireguard connection. Is it possible that because of this, the key for wireguard connection can be reissued earlier? If yes, how can I increase this parameter?
Pritunl has a lot of authentication methods that are expected to be enforced on every user connection. WireGuard uses a connection-less design that would have broken this requirement. To fix this in the Pritunl implementation a new WireGuard key is generated for every connection and the client sends keepalive requests. If requests are not received for a few minutes the key is removed. There is more information in the WireGuard documentation section.
The wg_public_key_ttl set by sudo pritunl set app.wg_public_key_ttl 604800 sets the maximum time that a WireGuard connection can exist, which defaults to 7 days. Changing this requires restarting at least one host to update the MongoDB index. I will increase this default to 90 days in the next release. There’s currently nothing that removes the unused documents before the expiration so there has to be an expiration but it could be significantly higher for most use cases.
Thanks for your reply. If we look at the user logs from the Pritunl server, we can see that in most cases the keys are updated after 7 days, but in some cases it triggers earlier. In the pritunl server and pritunl client logs there is a wireguard key re-acquisition. Why does it happen earlier than 7 days?
Could this be due to Transport Message Limits?
If so, how do you set it up to be as big as possible?
Thanks for reply. This sometimes happens when I restore a database from a backup via a Wireguard connection.
This means that the server could not have fallen asleep during the files transferring.
The size of databases sometimes exceeds 10 Gb.
Could this affect reconnections to Pritunl?
Are there any file transfer size limits at all through Pritunl VPN server using Wireguard?
Or for Wireguard, is the restriction only on public key time? (what can be a connection failure until the client is authorized with a new key?)
The service logs on the client would show any failure in the keep alive for the Pritunl connection management. There’s nothing related to data sent that should cause a connection to be dropped. The document you linked is referencing a data channel key similar to the Diffie–Hellman key exchange used in OpenVPN, that mechanism would not expire or effect the key that is stored in Pritunl to authenticate the connection.
That is from a handshake timeout. Once the connection is authenticated the client will watch sudo wg show $WG_INTERFACE_NAME latest-handshakes for 15 seconds for a successful handshake in WireGuard. If it doesn’t occur in 15 seconds the connection is restarted.
@zach thanks for your reply.
Could you please tell me can we increase this value?
If yes, how?
In general, is there any documentation that describes what parameters should be applied (enable, disable, increase) so that there are no gaps (reconnections)?
We have a problem with that. Sometimes it is necessary to restore PostgreSQL database via Pritunl VPN (Wireguard type). As the database is not small, it can take about 1–2 hours of time. Sometimes it breaks (reconnects) after 40–50 minutes when it is almost over.
Maybe you can give us recommendations?
This is the code in pritunl-client-electron/service/profile/profile.go where the error occurs. It is hard coded for 30 iterations with a 0.5 second delay. After you connect to the server quickly run sudo wg show $WG_INTERFACE_NAME latest-handshakes and check for any issues with the output. I haven’t seen this issue occur and it’s unlikely it would take more than 15 seconds if it were going to work at all.
I did do a few large tests over WireGuard to look for any limitations on total data sent. A 2 TB iperf between a Fedora client and Oracle Linux 8 server didn’t have any issues.
You need to check the service logs for other errors, the handshake timeout mentioned above is only for the connection. It’s possible the network traffic is slowing the ping checks to the server, the timeout which is only a 6 second timeout on the request. It is retried 4 times with a 1 second delay between each attempt before restarting the connection. This would show profile: Keepalive failed in the logs.
I will look into adding options to change the timeouts. If it’s a Linux client you can modify timeouts in the code and manually run it with the commands below.
go install github.com/pritunl/pritunl-client-electron/service@latest
cd ~/go/pkg/mod/github.com/pritunl/pritunl-client-electron@*/service
nano profile/profile.go
# edit Timeout: 6 * time.Second in clientInsecure
go build -v
sudo systemctl stop pritunl-client
sudo ./service
profile: Connecting ◆ device_auth=false ◆ disable_dns=false ◆ disable_gateway=false ◆ dynamic_firewall=false ◆ force_dns=false ◆ mode=“wg” ◆ profile_id=“iocruraomhld2lmf” ◆ reconnect=true ◆ sso_auth=false