Unable to successfully download PIA json payload from URL using token

[Rukongai]

Hey - I've been pulling my hair out over this one. I have iterated over dozens of setting changes trying to get this to work

Last night, my container was working as it had been for awhile. I restarted the host and when it came back up, I was no longer able to get it started properly while using strict port forwarding

I have recreated the container dozens and dozens of times, deleted the whole thing and set it up fresh, still can't get it to work.

The error that I'm getting is

[warn] Unable to successfully download PIA JSON payload from URL 'https://10.27.128.1:19999/getSignature' using token 'O9mvSIzSbgP2fXqnsVEGowfH2jU92nFlu+ibgn3q_pdoeBTlCgPxDz4K_vWMIPd9ZEiSahDhLFs3jMxROtCFDoAuFCuvX0UX4qrTHZ1b6TZAec95B8cfYVBxI9g='

I've tried with 4 different PIA endpoints, all which support port forwarding to no avail

I've attached a pastebin with a fresh container and supervisor log

https://pastebin.com/sFR4anr9

Is there a way to set verbose outputs on the container scripts? I was hoping to see the actual curl response for the curl to /getSignature, but I wasn't able to figure out how to edit the scripts easily.

Let me know if I can provide any other information!

[binhex]

my guess would be overlapping ip ranges, note your lan range:-

LAN_NETWORK defined as '**10.0.0.0/8**,172.16.0.0/16'

and then note the ip used fo the pia endpont:-

Unable to successfully download PIA json payload from URL 'https://**10.27.128.1**:19999/getSignature' using token

do you really need such a large netmask for your lan?, try setting that to a more sane value such as /24 or even /16 would stop the overlap

[zpdeering]

I'm also getting this same thing, and my LAN_NETWORK is set to 192.168.2.0/24 - is it possible something changed with the PIA endpoints? Here's my pastebin from a fresh container: https://pastebin.com/qeJwVr8P

Edit: added pastebin

[binhex]

im not sure what to say, im running latest image here and i just restarted the container connecting to pia endpoint ca-toronto.privacy.network and it worked straight away, this is using openvpn client.

double check your firewall and ensure you are not blocking pia endpoints.

[Rukongai]

Hey sorry - just woke up.

I don't know why it wasn't working. I ended up purchasing a sub to Mullvad

On the netmask - I originally had it broken out into smaller groups based on subnet, and the issue existed then as well - I had consolidated to /8 as a test and left it.

Interestingly enough when I switched to Mullvad, didn't fix my issue. However - I brought down all my docker containers and deleted every non-system docker network, and recreated them before bringing everything back up. That fixed it.

Couldn't tell you why or what happened, but that's where I ended.

Also - I wish I had written this down. But having the LAN_NETWORK and NAME_SERVER values enclosed in quotes may have also had an effect? I vaguely remember DNS lookup issues being resolved by quote blocking them. (docker-compose fwiw)

` - 'LAN_NETWORK=10.0.0.0/8,172.17.0.0/16,172.18.0.0/16,172.20.0.0/16,172.16.0.0/16'

• 'NAME_SERVERS=1.1.1.1,1.0.0.1'`

But yeah - I was pretty certain the issue was with my setup, I was just hoping for some guidance. Everything is working smoothly now, though.

I don't know if this would be worth implementing, but having some kind of verbosity setting we could enable to set verbose output on the script level might be nice!

Thanks for your hardwork and great containers. I can close this issue if you'd like.

[zpdeering]

im not sure what to say, im running latest image here and i just restarted the container connecting to pia endpoint ca-toronto.privacy.network and it worked straight away, this is using openvpn client.

double check your firewall and ensure you are not blocking pia endpoints.

I switched to using the PIA "openvpn-strong-tcp" bundle instead of the regular one, and now it works. Not sure what was going on before but it's all good now. Sorry for the trouble!