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,

Reply via email to