Fro those of you who use PIA and were not aware, they have updated the cert.  This is the important part...

 

All Private Internet Access users must update their desktop clients at https://www.privateinternetaccess.com/pages/client-support/ and our Android App at Google Play. Manual openvpn configurations users must also download the new config files from the client download page.

 

Here is the full email I received:

 

To Our Beloved Users,

 

The Russian Government has passed a new law that mandates that every provider must log all Russian internet traffic for up to a year. We believe that due to the enforcement regime surrounding this new law, some of our Russian Servers (RU) were recently seized by Russian Authorities, without notice or any type of due process. We think it’s because we are the most outspoken and only verified no-log VPN provider.

 

Luckily, since we do not log any traffic or session data, period, no data has been compromised. Our users are, and will always be, private and secure.

 

Upon learning of the above, we immediately discontinued our Russian gateways and will no longer be doing business in the region.

 

To make it clear, the privacy and security of our users is our number one priority. For preventative reasons, we are rotating all of our certificates. Furthermore, we’re updating our client applications with improved security measures to mitigate circumstances like this in the future, on top of what is already in place. In addition, our manual configurations now support the strongest new encryption algorithms including AES-256, SHA-256, and RSA-4096.

 

All Private Internet Access users must update their desktop clients at https://www.privateinternetaccess.com/pages/client-support/ and our Android App at Google Play. Manual openvpn configurations users must also download the new config files from the client download page.

 

We have decided not to do business within the Russian territory. We’re going to be further evaluating other countries and their policies.

 

In any event, we are aware that there may be times that notice and due process are forgone. However, we do not log and are default secure against seizure.

 

If you have any questions, please contact us at [email protected].

 

Thank you for your continued support and helping us fight the good fight.

 

 

 

 

Sincerely,

Private Internet Access Team

I saw this, but when I tried to convert early this morning it was a no go... not even the strong certificate method. I mainly want to see what the throughput reduction and increased CPU load would be with hardware crypto on my AM1 5350 board.

They got my full attention on my laptop when they killed the vpn connection and gave me a "new version" popup. Very subtle. lol

And now we need all docker with VPN be updated as well

 

//Peer

I saw this, but when I tried to convert early this morning it was a no go... not even the strong certificate method. I mainly want to see what the throughput reduction and increased CPU load would be with hardware crypto on my AM1 5350 board.

 

I have the same issue and reverted back to the old CA and port 1194.  The new CA and port 1198 fail outright!

I saw this, but when I tried to convert early this morning it was a no go... not even the strong certificate method. I mainly want to see what the throughput reduction and increased CPU load would be with hardware crypto on my AM1 5350 board.

 

I have the same issue and reverted back to the old CA and port 1194.  The new CA and port 1198 fail outright!

Interesting, working fine for me, 1198 endpoint is Netherlands using udp

 

Sent from my SM-G900F using Tapatalk

 

 

I saw this, but when I tried to convert early this morning it was a no go... not even the strong certificate method. I mainly want to see what the throughput reduction and increased CPU load would be with hardware crypto on my AM1 5350 board.

 

I have the same issue and reverted back to the old CA and port 1194.  The new CA and port 1198 fail outright!

Interesting, working fine for me, 1198 endpoint is Netherlands using udp

 

Sent from my SM-G900F using Tapatalk

 

What are you using for your OVPN client?  I'm using pfsense.

I saw this, but when I tried to convert early this morning it was a no go... not even the strong certificate method. I mainly want to see what the throughput reduction and increased CPU load would be with hardware crypto on my AM1 5350 board.

 

I have the same issue and reverted back to the old CA and port 1194.  The new CA and port 1198 fail outright!

Interesting, working fine for me, 1198 endpoint is Netherlands using udp

 

Sent from my SM-G900F using Tapatalk

 

What are you using for your OVPN client?  I'm using pfsense.

This is using a standard openvpn client which is baked into the VPN docker images I produce (deluge, tTorrent, sabnzbd)

 

Sent from my SM-G900F using Tapatalk

 

 

I actually got strong up and work, I was using the wrong port number! My pfSense box has an AMD AM1 5350 for a CPU and handles the load fine with hardware crypto.

I actually got strong up and work, I was using the wrong port number! My pfSense box has an AMD AM1 5350 for a CPU and handles the load fine with hardware crypto.

 

Is all you had to do was edit the CA and change the port in the OPVN settings?

Check the required ports for the encryption option you are using: AES-256-CBC/SHA256/RSA-4096 is on port 1197, AES-128-CBC/SHA1/RSA-2048 is on 1198, UDP.

 

https://www.privateinternetaccess.com/openvpn/openvpn.zip (AES-128-CBC/SHA1/RSA-2048)

https://www.privateinternetaccess.com/openvpn/openvpn-strong.zip (AES-256-CBC/SHA256/RSA-4096)

 

Looks like what PIA has dumped is the 128bit Blowfish encryption (BF-CBC/SHA1/RSA-2048) on 1194 UDP.  The new 'recommended' default is using AES-128-CBC/SHA1/RSA-2048 with a stronger 256/4096 option, both they have supported in their apps for a while just not advertised or had keys provided for manual config until December of last year.

I can get both standard and strong work in my OpenVPN plugin ( no need to modify any files)

But on the docker that I use VPN port 1197(strong) will not work but 1198(standard) is OK. SO it must be some issue with docker configuration for the strong Cert.

 

I will take this in the support tread

 

 

//Peter

 

Check the required ports for the encryption option you are using: AES-256-CBC/SHA256/RSA-4096 is on port 1197, AES-128-CBC/SHA1/RSA-2048 is on 1198, UDP.

 

https://www.privateinternetaccess.com/openvpn/openvpn.zip (AES-128-CBC/SHA1/RSA-2048)

https://www.privateinternetaccess.com/openvpn/openvpn-strong.zip (AES-256-CBC/SHA256/RSA-4096)

 

Looks like what PIA has dumped is the 128bit Blowfish encryption (BF-CBC/SHA1/RSA-2048) on 1194 UDP.  The new 'recommended' default is using AES-128-CBC/SHA1/RSA-2048 with a stronger 256/4096 option, both they have supported in their apps for a while just not advertised or had keys provided for manual config until December of last year.

 

Thanks ue.

 

However, when I change to the new cert and change my OVPN client to AES-128-CBC, port 1198, SHA1, I see this in the logs:

 

Jul 13 06:29:34	openvpn	18216	WARNING: 'cipher' is used inconsistently, local='cipher AES-128-CBC', remote='cipher BF-CBC'

 

Why is the remote side expecting BF?

 

That being said, it does appear to be up and running and my unRAID box (which is using the tunnel) is able to update containers...

 

Jul 13 06:29:37	openvpn	18216	Initialization Sequence Completed

 

John

Check the required ports for the encryption option you are using: AES-256-CBC/SHA256/RSA-4096 is on port 1197, AES-128-CBC/SHA1/RSA-2048 is on 1198, UDP.

 

https://www.privateinternetaccess.com/openvpn/openvpn.zip (AES-128-CBC/SHA1/RSA-2048)

https://www.privateinternetaccess.com/openvpn/openvpn-strong.zip (AES-256-CBC/SHA256/RSA-4096)

 

Looks like what PIA has dumped is the 128bit Blowfish encryption (BF-CBC/SHA1/RSA-2048) on 1194 UDP.  The new 'recommended' default is using AES-128-CBC/SHA1/RSA-2048 with a stronger 256/4096 option, both they have supported in their apps for a while just not advertised or had keys provided for manual config until December of last year.

 

Thanks ue.

 

However, when I change to the new cert and change my OVPN client to AES-128-CBC, port 1198, SHA1, I see this in the logs:

 

Jul 13 06:29:34	openvpn	18216	WARNING: 'cipher' is used inconsistently, local='cipher AES-128-CBC', remote='cipher BF-CBC'

 

Why is the remote side expecting BF?

 

That being said, it does appear to be up and running and my unRAID box (which is using the tunnel) is able to update containers...

 

Jul 13 06:29:37	openvpn	18216	Initialization Sequence Completed

 

John

Add 'verb 5' to the config and look at the chatter during connection.  It may be ignoring your custom port and using 1194 instead.  Go through the config file directly and check for issues.

 

Sent from my ASUS_Z00AD using Tapatalk