On 2019/05/27 15:17, Phillippe Lemarc wrote:
HAProxy implements ACLs via ebtrees 
(https://wtarreau.blogspot.com/2011/12/elastic-binary-trees-ebtree.html ):
"ACL: string and IP address matches rely on EB trees so that even very large pattern 
file do not cause any noticeable slowdown (eg: full internet BGP routing table)."

so to do a firewall rule on HAProxy it is quite straighforward to do the 

tcp-request connection reject if !{ src -f /etc/haproxy/myfile.zone }

Having worked with ipsets, loading IPsets can be quite a painful thing to do, 
so I'm not sure how efficient are compared to HAProxy ebtrees.

Someone from the mailing list might have more details, but the above should be 
enough to get a good response. A good question to ask Willy might be regarding 
the performance of ebtrees vs. ipsets.

Phillippe, thank you very much for the link to Willy's ebtree article, and for your example of using an ACL whitelist file with haproxy. It appears that performance of either ebtree or ipset are more than enough for my purposes. I agree that ipset loading is slow for large sets. I haven't noticed any performance problems once ipsets are loaded though.

On 2019/05/27 17:08, Aleksandar Lazic wrote:
I would use haproxies maps and runtime cli for your requirement instead of


I assume that a haproxy which is running in chrooted environment does not have
access to iptables but to the map files.

It would be also interesting which version of haproxy you have and how your
config looks like.

Aleksandar, thank you very much for the haproxy map & runtime socket api links. Haproxy maps are very powerful and I had not paid enough attention to them. I think they could work well for my use case.

The articles you linked also refer to:
which detail how haproxy can reload its configuration files without dropping any connections. Great to know about!

On 2019/05/28 12:21, Lukas Tribus wrote:
> For everyone that is not as familiar with ipset, like myself, can you
> elaborate why ipset is more flexible, easier to maintain and more
> convenient to set up than haproxy src ACLs or maps?

Lukas, a large part of the answer is my own unfamiliarity with haproxy. I'm not well qualified to give such a comparison. I naively assumed that since ipsets are "baked in" to Linux, it would make sense for haproxy to use them if possible. I forgot that haproxy can load a src ACL from a file -- which is easier for me to maintain than having to include all IP ranges in the haproxy config file itself. And I hadn't even thought of using a haproxy map for this purpose.

In case others are interested in ipset, here's a good article and the ipset man page:

FWIW as I now see it:

+ fast (with iptables)
+ "baked in" to Linux, seems it could be a "standard" solution allowing sets to be shared among kernel / haproxy / apache / etc if desired
+ sets easy to manage from command line/scripts
+ set updates are effective immediately
- large sets are slow to load
- not supported AFAICT from haproxy or apache

haproxy src ACL file:
+ fast (with haproxy)
+ easy to maintain simple file format
- restart required to update (but can be done without dropping any connections)

haproxy map
+ very flexible
+ fast
+ can be updated via socket api, no restart required
- syncing in-memory and on-disk state is more complex than simple file edit and reload


I now plan to use src ACL files with hitless reload. I might keep my whitelists & blacklists in files with slightly more elaborate syntax and use a script to translate them into ipset or haproxy ACL files as appropriate. For example, the ipset "nomatch" exception can be very handy for "punching out" ip subnets. A script could translate a single list file that included "nomatch" ranges into a haproxy whitelist and blacklist file pair to be combined in compound acl test.

Thanks for all the help!

Reply via email to