ProtonVPN does not have the same PrivateKey for all servers

[shalak]

trafficstars

URL to the Wiki page

https://github.com/qdm12/gluetun-wiki/blob/main/setup/providers/protonvpn.md

What's incorrect?

WIREGUARD_PRIVATE_KEY is your 32 byte key in base64 format. The private key can be obtained by generating a Wireguard configuration file and copy the displayed PrivateKey value. Note this value is the same for all ProtonVPN servers. 💁 Guide on how to generate a configuration file

~This is simply not true. Every time I generate a new wireguard config, the PrivateKey changes.~

~That being said - it appears that whole ProtonVPN configuration makes no sense, as if I use privkey from one server, and gluetun chooses different one, it won't work.~

~Or am I missing something?~

EDIT (leaving the above for context):

The documentation is somewhat misleading, it should say something among the lines of:

WIREGUARD_PRIVATE_KEY is your 32 byte key in base64 format. The private key can be obtained by generating a Wireguard configuration file and copy the displayed PrivateKey value. Note this value is differrent every time you generate the configuration, but each one works for all of ProtonVPN servers. 💁 Guide on how to generate a configuration file

[github-actions[bot]]

:warning: This is the Gluetun WIKI and any issue unrelated to the issue will be instantly closed as not planned without any explanation.

qdm12 is more or less the only maintainer so please:

• do not ask for updates, be patient
• :+1: the issue to show your support instead of commenting

qdm12 usually checks Wiki issues at least once per month and tries to resolve them all before a new Gluetun release.

[tribut]

What the documentation wants to tell you is that you can use every PrivateKey for any server of your choosing. A PrivateKey is not bound to one specific server or server region.

Of course, every Wireguard config you generate will have its own, unique PrivateKey. However, you can use these keys for all servers regardless what you choose when generating the config.

[maldis018]

A PrivateKey is not bound to one specific server or server region. [...] However, you can use these keys for all servers regardless what you choose when generating the config.

@tribut This appears to be no longer true. I suspect this may have changed recently. I just came here to open the same GH issue after troubleshooting this for an hour.

I was unable to get Gluetun to connect over WireGuard until I used the server that matched the one in the generated config file for the private key I'm using. It was a pain because I needed to find my server's name from servers.json, then use that hostname in my config.

[tribut]

Interesting. Did not have that problem until now and I just regenerated a wireguard key today. But maybe they are rolling out something gradually?

[maldis018]

Could be. I have a brand new account, so it could depend on when the account was made. @shalak When was your account made?

[shalak]

Could be. I have a brand new account, so it could depend on when the account was made. @shalak When was your account made?

Hmm, I have proton account for several years, but the VPN account in it is brand new.

I was unable to get Gluetun to connect over WireGuard until I used the server that matched the one in the generated config file for the private key I'm using. It was a pain because I needed to find my server's name from servers.json, then use that hostname in my config.

What I went with is simply this:

      VPN_SERVICE_PROVIDER: custom
      VPN_PORT_FORWARDING_PROVIDER: protonvpn
      VPN_TYPE: wireguard

Then I simply mount the gluetun/wireguard/wg0.conf and it works like a charm, with port forwarding and needs no hassle with looking up the ProtonVPN host addresses.

[tribut]

Here is what I just tried, can you tell me if the results are any different for you?

1. Create a new Wireguard Configuration:
   • Platform: GNU/Linux
   • Netshield: No filter
   • Moderate NAT: Off
   • NAT-PMP: Off
   • VPN Accelerator: Off
   • Server:Egypt / EG#1
2. Run gluetun with the following basic configuration

   services:
     gluetun:
       image: qmcgaw/gluetun:v3
       cap_add: [NET_ADMIN]
       devices: [/dev/net/tun:/dev/net/tun]
       environment:
         SERVER_COUNTRIES: Austria
         VPN_SERVICE_PROVIDER: protonvpn
         VPN_TYPE: wireguard
         WIREGUARD_PRIVATE_KEY: PrivateKey-from-wg-profile-created-above-here
   

3. Verify it works. My log says:

   INFO [healthcheck] healthy!
   INFO [dns] DNS server listening on [::]:53
   INFO [dns] ready
   INFO [ip getter] Public IP address is 87.249.133.98 (Austria, Vienna, Vienna - source: ipinfo)
   

[shalak]

Yep, looks like after all we can use Egypt's private key to connect to Austra endpoint:

gluetun-1  | 2025-04-14T08:53:22Z INFO [firewall] allowing VPN connection...
gluetun-1  | 2025-04-14T08:53:22Z INFO [wireguard] Using available kernelspace implementation
gluetun-1  | 2025-04-14T08:53:22Z INFO [wireguard] Connecting to 79.135.104.50:51820
gluetun-1  | 2025-04-14T08:53:22Z INFO [wireguard] Wireguard setup is complete. Note Wireguard is a silent protocol and it may or may not work, without giving any error message. Typically i/o timeout errors indicate the Wireguard connection is not working.
gluetun-1  | 2025-04-14T08:53:22Z INFO [dns] downloading hostnames and IP block lists
gluetun-1  | 2025-04-14T08:53:28Z INFO [healthcheck] healthy!
gluetun-1  | 2025-04-14T08:53:30Z INFO [dns] DNS server listening on [::]:53
gluetun-1  | 2025-04-14T08:53:30Z INFO [dns] ready
gluetun-1  | 2025-04-14T08:53:31Z INFO [ip getter] Public IP address is 91.132.139.3 (Austria, Lower Austria, Langenzersdorf - source: ipinfo)
gluetun-1  | 2025-04-14T08:53:31Z INFO [vpn] You are running the latest release v3.40.0

I'll update the ticket description.

[tonylaw7]

Echoing the steps mentioned by @tribut, I didn't encounter any issues using the same privatekey taken from one configuration to connect to different servers.

[maldis018]

I suspect this was a temporary issue for keys issued during a particular window. I started having the issue shortly after this issue was created, then was no longer able to reproduce by April 14 when tribut ran the test.

[qdm12]

Wording adjusted in d6f1ae5b9c8dde2de4bb414cd564cb724c805825

[github-actions[bot]]

Closed issues are NOT monitored, so commenting here will NOT be seen by the maintainer. If you think this is still unresolved and have more information to bring, please create another issue.

This is an automated comment setup because qdm12 is the sole maintainer of this project which became too popular to monitor closed issues for additional comments.