Hi Lukas, On Tue, May 28, 2019 at 06:21:28PM +0200, Lukas Tribus wrote: > Hello Frank, > > On Mon, 27 May 2019 at 20:52, Frank Myhr <fm...@fhmtech.com> wrote: > > > > Hi, > > > > I have a setup with multiple domains that resolve to a single public IP > > address, with https handled by haproxy using SNI feeding an apache http > > backend using name-base virtual hosting. Access to some (but not all) of > > the virtual hosts should be restricted to a list of ip address ranges. > > > > I'd like to use ipsets for this access control, because they are > > convenient to set up and maintain, and because they've been working > > great in other setups where I use them from iptables. > > [...] > > I suppose canonical ways are haproxy src ACL or apache > > require ip. Both seem (to me) to be less flexible and harder to maintain > > than ipsets. > > 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?
For me they are used exactly the same way, except that with ipset you have an external utility while for haproxy you have to do it yourself. If we had a simple script to add/remove networks from ACLs/maps both in the file and on the CLI at the same time, it would be used exactly the same way. Frank, I've wanted to support ipset 10 years ago or so, before we had the ability to update ACLs at run time. I also wanted to be able to update them at run time. But later I figured that 1) it wouldn't bring any extra functionality over ACLs, 2) would not be portable, 3) would require haproxy to run as root in order to support being updated at runtime. So overall it would add extra dependencies and deployment constraints with little to no real benefit. Hoping this helps, Willy
