Working OpenVPN (PIA) just stopped working?!
-
Yes, I am using 2.4 Beta.
I don't think their end is working fine because last week I did't changes anything to my configuration (Beta update, configuration change).
-
-
Tried VPN user/pass in auth file (how it was originally) & in GUI fields
-
Disabled IDS/IPS & cleared snort2c table to ensure it wasn't blocking anything
-
Scrubbed my zpool to ensure no corruption
-
-
Hmm, when I try to submit an ticket on the site of PIA, it shows:
High Volume Queues We are currently experiencing higher than average ticket queues due to recent Customer Support and network changes. Please be assured we will answer your ticket.
So it seems they changes something and working on it.
-
At the time I noticed the issue I was still on beta release that was more than a week old. May have been a June 13 release… I made no changes to the config or update before the connection went down.
-
You shouldn't have to neg a cipher - you should set your client to use the cipher they are using.. This is going to prevent a shitton of problems..
Its possible they changed their config so before they had multiple ciphers possible, and now they only have the BF.. Change your client to use BF and see if you can connect.
edit: I just upgraded mine to the latest build, remotely even. built on Wed Jun 21 01:52:48 CDT 2017
It rebooted and I am back on the vpn from work without any changes having to be done. Currently running 2.4.3 on work machine, and my phone can connect in just fine as well. And the vpn client I have from pfsense to my VPS is up and running as well, so clearly latest 2.4 build did not break openvpn ;)
I like the new blue login screen btw… And openpvn on this build is
Jun 21 14:18:01 openvpn 45809 OpenVPN 2.4.3 amd64-portbld-freebsd11.0 [SSL (OpenSSL)] [LZO] [LZ4] [MH/RECVDA] [AEAD] built on Jun 21 2017My previous build was
Jun 21 14:17:02 openvpn 46849 OpenVPN 2.4.2 amd64-portbld-freebsd11.0 [SSL (OpenSSL)] [LZO] [LZ4] [MH/RECVDA] [AEAD] built on May 12 2017Since you did not change anything - I would think they broke something on their end. I can connect to pfsense from multiple devices, and my pfsense can as a client connect to a server I run..
-
My client is configured in a known working configuration. It's setup using the correct certificate on the correct port for the cipher and authentication that I'm using.
PIA made a post (I linked it a few posts earlier) stating that all those warnings are saying is that I'm requesting to use a cipher, auth, etc. that is non-default, but it will still work and connect in the method requested by the client. They are warnings not errors.
I did try changing my end to match the warnings, it doesn't do anything except fail with the same error sans those warnings.
-
It looks like it was on PIA's side. My desktop connection cycled, then my pfSense connection came back up with 0% packet loss. It looks like they fixed whatever it was on their end!
-
It is working again.
PIA instructions here https://helpdesk.privateinternetaccess.com/hc/en-us/articles/218984968-What-is-the-difference-between-the-OpenVPN-config-files-on-your-website- state:
"connect over UDP port 1198 with AES-128-CBC+SHA1, using the server name to connect."
And instructions here https://helpdesk.privateinternetaccess.com/hc/en-us/articles/225274288-Which-encryption-auth-settings-should-I-use-for-ports-on-your-gateways-
confirm using UDP port 1198 with AES-128-CBC and SHA1
This was my working config on a 2.4.0 beta release a week old. I did not make a change in the router config nor did I perform an update; it simply stopped working. However, I have a Tomato router that is using the same credentials, .crt, and username/password and it connects.
Strange that it was functional on a Tomato router during this 4 hour period but not on pfSense.
-
I spoke too soon. Down again on pfSense but still working on Tomato.
-
Now working on UDP port 1197 with AES-256-CBC and SHA256
-
Strange that it was functional on a Tomato router during this 4 hour period but not on pfSense.
Yeah that's really weird, or maybe not weird I just don't know the technical details to explain the reason why. My desktop client also never had an issue connecting on the same settings to the same server that pfSense was trying to.
-
I spoke too soon. Down again on pfSense but still working on Tomato.
Mine is still up on pfSense.
I wonder what's going on.
-
Working for 8 hours without issues on UDP port 1197 with AES-256-CBC and SHA256.
Seems it was an issue on the PIA side.Update: No issues since