I don't think this is the issue for any of the other people in the thread right now, but I wanted to make another post with an issue I had/have and tentatively solved.

I've noticed PIA has been quite flakey over the past few weeks, and posts on the PIA subreddit indicate I'm not the only one. The problems seem to be related (but possibly not limited) to some API change to port forwarding. Their support staff is being really evasive about this and it's unclear what they're doing.

I was using the ca-toronto .ovpn file, which up until recently was working fine. Following the suspected API change the Toronto endpoint was for some reason no longer supported. The confusing part is that Toronto is the list that the script produces (under ca-toronto.pvt.site). I imagine this would be rather confusing to anyone trying to understand the problem from logs, but not technical enough to inspect the container or understand why it broke.

One of the trackers I use requires port forwarding so this was the source of considerable frustration. However, I think I was able to resolve it by switching to Wireguard and changing the wg0.conf endpoint to ca-toronto.pvt.site. I did this earlier today and actually gave up on it because it didn't seem to be working on that tracker, but was still functional for normal trackers (and I didn't have any more time to devote to it). But a few hours later I checked the tracker and surprisingly it was connectable and seeding. The delay was probably due to the site not updating frequently, but it's worth pointing out for others who might be actively debugging as I was.

For anyone else with a similar issue, switching to Wireguard is an easy thing to try before you spend too much time getting OpenVPN to work.

Edited October 16Oct 16 by nft2
Removed an erroneous conclusion about the ovpn file being broken.

47 minutes ago, nft2 said:

I'm not sure why PIA made this change without updating the configs they let you download,

The ovpn file doesn’t get any sort of automated update. It would have to be updated manually by you to change the endpoint. PIA has changed the names of a fair number of their port forwarding sites over the past couple of months and will probably continue to do so.

FYI- this problem can also happen with the wg0 config file.

Hello all, I'm having trouble trying to save the mover.Py file to the appropriate location. I simply cannot find it. I know this should be relatively easy but it's driving me nuts. My diagnostics is below if anyone can help me.

/mnt/user/appdata/scripts

nas-diagnostics-20261016-0050.zip

I tried to post to diagnostics area but they suggested post here...

Edited October 16Oct 16 by WanderingGander.87
Add location.

On 10/15/2026 at 12:28 PM, binhex said:

You didnt answer this question directly, what is the ip address of the machine?, i want to ensure LAN_NETWORK is defined correctly (a very common trip up), keep in mind if your machine is on a different VLAN it will be blocked irresepective of your VLAN ruleset.

Can you also tell me is the network for the container is set to bridge?, i have a feeling its not, if not please switch it to bridge then try again.

Thank you! The LAN_NETWORK suggestion let me in the right direction.
Even though I've put the docker on a separate VLAN 10.0.1.0/24, I had to enter 10.0.0.0/24 in the LAN_NETWORK for it to work :)

46 minutes ago, GnaXi said:

Thank you! The LAN_NETWORK suggestion let me in the right direction.
Even though I've put the docker on a separate VLAN 10.0.1.0/24, I had to enter 10.0.0.0/24 in the LAN_NETWORK for it to work :)

The LAN_NETWORK setting is for networks that you want to have access to the app, not necessarily the same as the network the docker is using. If you are using some other network to access the app remotely you may also need to enter it. Comma separated.

8 minutes ago, nft2 said:

I understand that. The configs that are currently downloadable on the site are what don't match the values on the server list. If you're talking about the configs zip on their site not getting an update when they change it, it should.

I see, your saying that if you download a new ovpn file the endpoints are wrong.👎

1 hour ago, wgstarks said:

I see, your saying that if you download a new ovpn file the endpoints are wrong.👎

Thinking about this I realized that this problem specifically might not be a PIA issue (though as I said there is some ongoing debacle involving port forwarding). Too much posting and too little sleep. During my debugging I changed the .ovpn config to have the ca-toronto.pvt.site endpoint, but that didn't work. Meaning the .ovpn file is still correct for its purpose.

Let me experiment with this for a bit and see what I can put together.

Update: I was able to fix this in the container. I guess previously the DNS endpoints matched the ones in the .ovpn consistently. Anyway I submitted a PR https://github.com/binhex/arch-int-vpn/pull/60.

Thanks again to @binhex for this project. If this helps out, I'm glad I could lend a hand.

Edited October 16Oct 16 by nft2