HEADS UP: relayd deprecated on pfSense 2.5.0
-
FYI- relayd has now been removed from master (pfSense 2.5.0)
https://github.com/pfsense/pfsense/commit/586c623a943f59486a461c1af9873dd6cc11a3b3
-
@jimp
Would the removal of "relayd" effect Dual WAN load balancing that's currently integrated into pfsense? -
@kossie said in HEADS UP: relayd deprecated on pfSense 2.5.0:
@jimp
Would the removal of "relayd" effect Dual WAN load balancing that's currently integrated into pfsense?No, that never used relayd. This is server load balancing only.
-
Perfect thanks for the quick reply! I look forward to testing 2.5.0 when released.
-
It looks like I posted originally in the wrong section.
https://forum.netgate.com/topic/142176/relayd-going-away-in-2-5-0
haproxy unfortunately doesn't have the one big feature relayd has... established connections are not broken when switching to the backup firewall. We have some applications that get load balanced that have long living connections and 24/7 use that customers will get disconnected if an established connection breaks. Relayd was a nice solution for that.
Anyone know if this will ever return if relayd gets fixed or anyone else with similar requirements have a plan when 2.5.0 is released?
-
At this point it is unlikely to return. The upstream code hasn't been touched in years, and I don't see any sign of anyone working on it. It's not something we have the resources to take on, either.
Pretty much all the solutions out there now are proxies. I don't think there is anything left that would work purely with NAT.
If you only need load balancing and not failover or taking out servers from the pool, you could just make a port forward NAT rule with an alias for the target. Not fancy, but it may get the job done. Problem is that it can't handle server failures. Maybe with some custom scripting to monitor and add/remove from the target table... Still seems like a lot of room for error.
Failover with haproxy should be pretty quick. If your application can't handle a minor TCP connection hiccup gracefully, it probably has more problems than reconnecting on failover, though. You're far more likely to have the connection die due to random Internet happenings than failover.
-
I will research the alias option with port forward NAT. That might be ok for some scenarios. Thanks for that info. I will certainly miss relayd's failover connection handling. It worked well for our scenario.
-
there is another reason for keeping relayd or an equivalent firewall-level service
i believe running and exposing extra services on a firewall to be a potential security hole. this is especially true since haproxy is not isolated in a jail nor reasonably protected. and anyway, attacks such as hartbleed clearly demonstrated this offers a whole lot of other L4 protocol-based attacks
... and i do use haproxy since the earliest versions and really love it. actually i use relayd in front of haproxy quite often : the job of the firewall is to detect a dead haproxy. the job of haproxy ( or nginx or lighttpd or whatever ) is to perform better L7 health checks and possibly replay dead queries on a different server when needed.
using aliases does work, but afaik pf does not properly fail over to a different server when needed. additionally, there is no failover pool
-
Actually that's not an argument for keeping a service like relayd, it's an argument for not having anything like it on the firewall at all. If you are concerned, then the service should be performed by a dedicated and isolated server, not by the firewall.
-
sure. but how are we supposed to achieve redundancy ? obviously carp, vrrp and the likes come to mind but i believe it is much more efficient to have minimal intelligence on the firewall level so we can use multiple independent proxies efficiently, and possibly running differnet operating systems and software on different isolated networks. it is also very helpful during migration tasks to achieve complete transparency.
-
What does CARP has to do with security on the firewall platform? Or with additional services like relayd or haproxy? CARP is protocol and low level services, how'd you want to "exploit" that from WAN?
If you're arguing (and that is OK and depends on your level of security you want to define) that additional services on the firewall should be minimal, then yes, you'd have to put them in some sort of DMZ behind the (first) filter/gateway. I don't get the relation between stuff like CARP or L4 stuff like relayd or even L7 proxies. That's all over the place ;) -
Those are all topics for another thread. You would achieve it the same way you would for any other service off the firewall.
I've locked this thread as it's purpose has been served.
