Bug #4550
closed
relayd does not work with HTTPS monitor on FreeBSD 10.x and above with certain cipher combinations
0%
Description
Load Balancer monitor when set to Type:https reports all nodes of the cluster as down, whereas other monitors (such as tcp) against the same servers (and same pool) report the servers as up. Ports are open on the servers and the https type worked on at least version 2.1.3 (2.1.5 was skipped). Problem first noticed on 2.2, and still exists when upgraded to 2.2.1
Files
| loadbalancemonitor.JPG (30.9 KB) loadbalancemonitor.JPG | Screenshot showing 2 pools with only change being the monitor |
Updated by Jim Pingle about 10 years ago
- Subject changed from Load Balancer does not work with HTTPS monitor on 2.2 and above to relayd does not work with HTTPS monitor on FreeBSD 10.x and above with certain cipher combinations
- Status changed from New to Rejected
- Target version deleted (
2.2.2)
I hit this before working with a customer and tracked it down, it's an issue with relayd (even a current relayd) on FreeBSD 10.x and the ciphers offered by the web server(s). I setup a local test and with a default apache 2.4 SSL setup it works:
SSLCipherSuite HIGH:MEDIUM:!aNULL:!MD5
It fails with other cipher lists such as:
SSLCipherSuite RC4:TLSv1:-MD5:-aNULL:-MED:-LOW:-EXP:-NULL
It also fails with the cipher list given in the apache config example for "speed optimized" and it also fails with the cipher list we use for the pfSense GUI (on 2.2 at least, it has changed since my last test).
If I place some other cipher first such as AES128-SHA, or HIGH for example, it starts to work again.
It's still not clear if it's a relayd quirk, or something specific to FreeBSD, or OpenSSL, etc. About the only thing I haven't tried is a test purely on OpenBSD which wouldn't be as useful but may at least show if it's specific to relayd rather than the other factors.
At least we know that adjusting the SSLCipherSuite should be able to get it working again, though perhaps not an ideal solution, it's as far as we can take it ourselves. It'll need to be reported upstream to FreeBSD and/or the relayd maintainer (See http://www.freshports.org/net/relayd/ for contact info ) for a proper long-term resolution.
I've tried it with relayd (current version from pfSense and the latest in FreeBSD ports) on pfSense and FreeBSD directly and the problem was present there as well, so it is not specific to pfSense.
As an alternative, use the HAProxy package which is better in this role in nearly every way.
The /var/etc/relayd.conf file may be taken from pfSense and placed onto any FreeBSD box with relayd installed to test.