Any news about relayd?
Does anyone know whether there is any plan or any news about relayd ???
I understand the reasons of Netgate and the problems with openssl and libressl but maybe there is any news o info about its future..
No plans to bring it back. Definitely not in base.
The FreeBSD port was changed to use libressl, but we don't want to bring that in just for relayd.
Nearly all use cases of relayd are better served by haproxy, so there isn't much interest from anyone in putting time toward making a package for relayd, especially given its other problems and stagnant/nearly abandoned development.
Thanks @jimp ...
i understand it.... it is a pitty... Haproxy is a proxy, not an IP Load balancer so we cannot use it...
NAT based load labancing is not an option either... relayd worked so well!!!
Thanks again Jimp!
@pedreter I am also in this same boat. We used relayd for some time and it did it's job flawlessly. We tried using HAProxy, and it works somewhat for our purpose, but it seems to have some problems with websockets and other special links we have on our webserver, and so it breaks our web pages.
Does anyone know of any other solution that would be more like relayd?
i agree... relayd was the main reason to use PfSense... :-(
In Linux there is something similar: "Balance" and works very very well... i wilk check if there is a freebsd version... if so, maybe Netgate can consider it...
@stepariley @pedreter We are also in the same boat. We are using relayd and can not upgrade to 2.5 because of this.
HAproxy adds extra overhead and require the use of SSL offloading (keys on pfSense) if we want to know the source IP at web server level.
We need a solution where the web server does the SSL decryption and get the correct source IP. Relayd does all this with minimum resources needed - HAproxy does not.
I hate to say this, but switching to OPNsense seems to be our only solution.
You don't have to do SSL in haproxy. Set up ssl/HTTPS TCP forwarding instead of HTTP/HTTPS offloading in the frontend. There is also an option in haproxy backends called "Transparent ClientIP" which forwards the connections with the actual client source address intact. Though these days most web servers and web applications are smart enough to properly handle
X-Forwarded-Forheaders so requiring the true client address on the backend servers is rarely necessary as it may have been in the past.
If you make a post on the proxy category here with your requirements, someone could probably help you do what you want in haproxy.
Thank you for the reply. I have previously researched the solutions you suggest.
First, X-Forwarded-For does (obviously) not work when using TCP forwarding in HAproxy. The proxy cannot add an extra header to the HTTP request if the request is encrypted. HAproxy tries to solve this using the PROXY protocol, but that does not work with Microsoft IIS (any version).
HAproxys transparent IP is an advanced source IP spoofing that requires a very specific setup in regards to the internal servers remote gateway settings. It won't work with our current setup. We could possibly change our server to make it work, but really - all this extra work for what? Just a much more complicated setup with extra load on our firewalls, larger attack surface (proxy vs NAT) and a non-standard hack to route return traffic (when using transparent clientIP).
Relayd is very simple and much more secure by design. Even if there is a problem with the SSL implementation in relayd it is only used for the internal checking of server status (I assume), so it wouldn't be a serious threat to our servers.
Since relayd is simple, we can probably write a small script and have it run every second or so. Checking the server status with curl and modifying an NAT alias with aliasmod would actually be pretty similar to relayd in our case. I'm just a bit annoyed by the assumption that HAproxy can do what relayd does, because that is just plain wrong.