HAProxy package¶
HAProxy is a free, very fast and reliable solution offering high availability, load balancing, and proxying for TCP, HTTP and HTTPS-based applications. It is particularly suited for web sites struggling under very high loads while needing persistence or Layer7 processing.
Supporting tens of thousands of connections is clearly realistic with todays hardware. Its mode of operation makes integrating it into existing architectures very easy and riskless, while still offering the possibility not to expose fragile web servers to the Net.
Refer to the following articles for more information on the listed topics:
See also
Package Variants¶
Two versions of the haproxy packages are available on pfSense® software:
- HAProxy:
Tracks a stable version of FreeBSD port.
- HAProxy-devel:
Uses haproxy-devel from FreeBSD ports and loosely tracks a HAProxy development branch.
New features are added to the HAProxy-devel package first then later copied over the HAProxy package.
For info about HAProxy versions, see: https://github.com/PiBa-NL/pfsense-haproxy-package-doc/wiki
Recent Changes¶
See github log for recent changes:
Known issues¶
HAProxy has a list of known bugs by branch and by version.
See also
The pfSense software issue tracker contains a list of known issues with this package.
Differences between this package and HAProxy used directly¶
HAProxy defines five main sections in its configuration.
- Global
Defines options that process-wide and often OS-specific.
- Defaults
Sets default parameters for all other sections following its declaration.
- Frontend
Describes a set of listening sockets accepting client connections.
- Backend
Describes a set of servers to which the proxy will connect to forward incoming connections.
- Listen
Defines a complete proxy with its frontend and backend parts combined in one section. It is generally useful for TCP-only traffic.
In the pfSense software package, tabs exist to define “frontends” and “servers” but the resulting configuration is actually made up completely of listen sections. This is okay for the most part, but it does prevent advanced usages that need to refer to several backends and the like.
In HAProxy, a single server directive can be made with a blank port and it will listen on all the ports of the frontend that it is assigned to. The package GUI implies that this will be the case by leaving the port blank.
What actually gets generated instead is a single server directive for each port that the frontend is listening on. This is an important difference when the ports that are being listened on are not interchangeable. Example:
Define a front end for SMTP connections listening on ports 25 and 465. The server is listening on both of those ports, but 25 does not accept SSL/TLS and 465 does. When someone connects to the proxy on port 25, they should get connected to the server on port 25, and when they connect on 465, they get connected to the server on port 465.
In a standard HAProxy configuration where the frontend is set to listen on both ports and a single server directive is made with no port, it will operate the expected way.
In pfSense software, two server directives will be generated; one for each port. HAProxy will not send connections the expected way. It will loadbalance between them, regardless of whether the frontend and server ports match.
Therefore in pfSense software a separate frontend must be created for this, as they are essentially different services. Listen on port 25 and 2525, and it doesn’t matter whether someone connected on one port gets directed to the other, then they can be combined.
Splitting the servers up by port also means that a separate entry will exist for each one in the stats page, but the port will not be shown. In an HAProxy configuration where a single server directive has no ports and effectively handles multiple (due to inheriting from the frontend) it will only show up in the stats once.