Working OpenVPN (PIA) just stopped working?!
-
pfSense 2.4.0 runs OpenVPN 2.4.x, I haven't paid attention to which .x version is released with latest BETA builds, but I haven't sideloaded anything if that's what you're asking.
The "used inconsistently" logs I think I've always gotten? The VPN server I connect to is an AES-256-CBC, SHA-256 server, as is the CA I use. Nothing changed there, on my side at least. Possibly the provider changed their config? But I doubt it because I verified their CA today and it's the same as always?
-
"WARNING: 'cipher' is used inconsistently, local='cipher AES-256-CBC', remote='cipher BF-CBC'"
I don't see how it would ever work if your not using the same ciphers..
-
Why would that have changed then?
It looks like the latest 2.4.0 BETA broke OpenVPN, but idk why it would change the cipher that the provider is using?
https://forum.pfsense.org/index.php?topic=132538.0
-
I googled it and I was right, I have always received these warnings and they are normal. This isn't the issue.
https://helpdesk.privateinternetaccess.com/hc/en-us/articles/225409027-Why-do-I-get-cipher-auth-warnings-when-I-connect-
I see the same warnings from my VPN server if a client tries to connect with a non-standard or incorrect cipher, but it always just negotiates a working cipher and continues on.
-
Today PIA (Private Internet Access) VPN stop working after years of trouble free operation. Log file show: "AUTH: Received control message: AUTH_FAILED". Does your log file show this also?
On the site of PIA I can login with credentials.
Warnings about cipher are there for a long time and seems unrelated.
Also I did not update pfSense today, so problem seems to be at PIA side. Maybe related to new OpenVPN vulnerability, https://forum.pfsense.org/index.php?topic=132534.0. -
I do have that message in my logs.
Are you on pfSense 2.4.0 BETA?
I can connect (connected as I type this) to a PIA tunnel via their windows app using the same server, encryption, SHA & RSA settings as my pfSense uses. So I'm not sure what trouble PIA would be having, it looks like their end is working just fine?
-
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
-
@Presbuteros:
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.
-
@Presbuteros:
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
