Bug #10560
closed
Connection fails connecting to (my) OpenVPN instance.
0%
Description
When connecting using either OpenVPN Connect on Android using client certificate + username/password or OpenVPN client on a raspberry Pi using only certificate (different server instance of course) connection doesn't work.
It worked in OpenVPN 2.5.0 from 2019-09-19, but not in the daily named 2020-05-14.
I have tracked it down to /usr/local/sbin/ovpn_auth_verify calling fcgicli during cert validation.
The expected response to "RESULT=$(/usr/local/sbin/fcgicli -f /etc/inc/openvpn.tls-verify.php -d "servercn=$2&depth=$3&certdepth=$4&certsubject=$5&serial=$serial&config=$config")" is "OK", but the response received is "Something wrong happened while reading request" which is a response from inside the fcgicli binary:
ch = read_packet(sb, fcgisock, header);
if (ch < 0) {
printf("Something wrong happened while reading request\n");
//sbuf_finish(sb);
//sbuf_delete(sb);
break;
}If I override the response with "OK" in the script file (which is obviously only a hack) the connection succeeds.
I get the exact same response if I call the binary on a command line using the same options.
Updated by Stefan Smietanowski almost 4 years ago
Obviously meant pfSense 2.5.0 and not OpenVPN 2.5.0 ...
Updated by Stefan Smietanowski almost 4 years ago
And with "the same options" I mean if I use the same command line as is used (I modified the script to print out all options and then used them).
Updated by Jim Pingle almost 4 years ago
- Status changed from New to Not a Bug
This is working fine for myself and others, so it's almost certainly a problem in your config or environment and not pfSense or OpenVPN specifically. Going from September snapshots to May is a pretty big jump. You should investigate local fixes first, like taking a backup and reinstalling. If that doesn't help, post on the forum with more information about your setup and other log entries.
The fcgicli bit is probably a red herring. Definitely not a general issue.
Updated by Stefan Smietanowski over 3 years ago
TL;DR: It is a bug or feature of fcgicli in fact. It doesn't handle long strings being sent to the application. The "-d" option.
I found some time to run some tests and started with a clean installation, using the same certs, but regenerated everything but the root CA - same results.
When I was certain it was all correct, I dug down and found the following:
If you shorten the string passed to "-d" in ovpn_auth_verify, everything magically works. 231 characters work, 232 don't. I tried this by cutting down the "certsubject="-portion of the string.
RESULT=$(/usr/local/sbin/fcgicli -f /etc/inc/openvpn.tls-verify.php -d "servercn=$2&depth=$3&certdepth=$4& certsubject=$5 &serial=$serial&config=$config")
The php-code mentions a future case where one would want to validate the CN=, but that code is commented out. I can't find any other places where the certsubject is even used.
I haven't checked how older code does it, but there's the reason. It will work if you have a shorter string than what I have.
/usr/local/sbin/fcgicli -f /etc/inc/openvpn.tls-verify.php -d "servercn=My+Server+Name&depth=2&certdepth=1&certsubject=C=SE, ST=Sweden, L=Stockholm, O=Stesmi, OU=Long Certificate Authority Name, CN=Even Longer Common Name, emailAddress=my.email@example.com&serial=62859527549128549742879562845100457614589332286&config=/var/etc/openvpn/server1/config.ovpn"
With a shorter string it magically works, so I'm not surprised people don't reproduce it, maybe you use shorter strings?
I suggest this bug be reopened, as it in fact is a bug. Or at the very least it should be documented to shorten the names.
// Stefan
Updated by Jim Pingle over 3 years ago
We already have an issue for that particular problem: #4521
Updated by Jim Pingle over 3 years ago
- Status changed from Not a Bug to Duplicate