Failing obtain auth key due to blocked host

[sadontsev]

Hello everyone,

Could you suggest a solution to the PIA host being blocked by my ISP?

I see in the container logs:

Failed to acquire new auth token. Response:
Sun Jun 16 11:28:29 UTC 2024: Failed to acquire new auth token
Sun Jun 16 11:28:29 UTC 2024: Fatal error

I tried to call the token endpoint manually https://www.privateinternetaccess.com/api/client/v2/token

And it's unreachable from my ISP but reachable first enabling PIA VPN on my Mac.

[thrnz]

It looks like their desktop app might pick an api endpoint from the serverlist rather than using the fixed privateinternetaccess.com one:

https://github.com/pia-foss/desktop/blob/master/daemon/src/metaserviceapibase.h

I wonder if thats something the container could do if needed. It looks like it still might need to access https://serverlist.piaservers.net/vpninfo/servers/v6 though to find an endpoint. I don't suppose thats also blocked?

[sadontsev]

It looks like their desktop app might pick an api endpoint from the serverlist rather than using the fixed privateinternetaccess.com one:

https://github.com/pia-foss/desktop/blob/master/daemon/src/metaserviceapibase.h

I wonder if thats something the container could do if needed. It looks like it still might need to access https://serverlist.piaservers.net/vpninfo/servers/v6 though to find an endpoint. I don't suppose thats also blocked?

Yes, good point. The server list (maybe being on a different host?) is reachable. I prepared a patch that seems to be "good enough" for now that overrides the auth script with a static token stored locally on the host (without refresh) and then the VPN can be connected. Surprisingly for me, I tried reconnecting the VPN today with the same token obtained on Sunday and it's still not expired.

I wonder if the tokens are permanent?

I wasn't able to find PIA API documentation myself to get an answer

[thrnz]

I don't think I've ever noticed an auth token expiring before. My Docker install is only a few weeks old at the moment, but it looks like the initial tokens are still being re-used on container creation.

110 adds optional env vars to override the API endpoints as a workaround in case the defaults are inaccessible, and should hopefully work for both generating the auth token and for downloading the server list. META_IP and META_CN env vars can be set to one of the 'meta' servers found in their server list (eg. META_IP=95.181.238.2 META_CN=bahamas404), and doesn't need to be the same as the LOC env var. META_PORT doesn't need explicitly setting and defaults to 443, but it looks like 8080 might also be an option.

If the server list is working as-is, then the env vars might only need setting on the initial run to generate the auth token, assuming /pia is being stored as a persistent volume/mount.

I've built and tagged it as thrnz/docker-wireguard-pia:testing on Docker hub if you're keen to test it out.

[sadontsev]

@thrnz amazing one :)

Works like Swiss watch:

Wed Jun 19 07:10:54 UTC 2024: Generating auth token
Fetching next-gen PIA server list via meta server: ip: 156.146.62.193, cn: zurich407, port: 443
Verified OK
Verified server list
Registering public key with PIA endpoint; id: swiss, cn: zurich407, ip: 156.146.62.207
Generating /etc/wireguard/wg0.conf
Using PIA DNS servers: 10.0.0.243,10.0.0.242
Port forwarding is available at this location
Successfully generated /etc/wireguard/wg0.conf

I specified both meta IP and CN

[sadontsev]

@thrnz is it something you would consider moving to master?

[thrnz]

It's been merged and should be in the latest build on Docker Hub.