# I can 'replace' iptables + ipset with acl src -f (?)

**URL:** <https://discourse.haproxy.org/t/i-can-replace-iptables-ipset-with-acl-src-f/6216>\
**Category:** Help!\
**Created:** [February 3, 2021, 10:55pm UTC](https://discourse.haproxy.org/t/i-can-replace-iptables-ipset-with-acl-src-f/6216 "2021-02-03T22:55:42Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![f1outsourcing](https://avatars.discourse-cdn.com/v4/letter/f/a183cd/32.png) [@f1outsourcing](https://discourse.haproxy.org/u/f1outsourcing)\
**Post date:** [February 3, 2021, 10:55pm UTC](https://discourse.haproxy.org/t/i-can-replace-iptables-ipset-with-acl-src-f/6216/1 "2021-02-03T22:55:42Z")

</div>

I was wondering what are the closest options to have something like iptables + ipset functionality in haproxy, and what the performance difference is. I have been looking a bit at this manual about dos protection[1].

Is the blacklisting with acl’s in files still the way to go with haproxy 2.2?

`http-request deny if { src -f /etc/hapee-1.8/blacklist.acl }`

I read some article that ipset had hardly any influence on the latency if it would contain ~50k entries. However you had to specify if you want a /24,/16 or individual ip set. Currently I have sets for rdp, web, smtp, pop/imap and ftp access, some have 60k entries.

From the example I see that I can list /23, /24 just in one file.

If specify in the file 1.1.4.0/24 and 1.1.4.1 will haproxy still process two lines or will 1.1.4.1 be disregarded?

Should this acl file be sorted? Or does it not matter how ip addresses are in the file, because haproxy optimizes this when loaded into memory?

How much memory would a list of ~50k entries use?

Is it better to just use one acl list for each service/frontend or is there next to no loss to use multiple, like this?

`http-request deny if { src -f amazon-google.acl } || { src -f custom-blacklist.acl }`

If I add an ip address to the acl via the admin socket[2], will this automatically be written to the acl file?

And a bit out of curiosity, how does blacklisting via acl’s compare to ipset in with added latency?

[1]

> **[Application-Layer DDoS Attack Protection with HAProxy](https://www.haproxy.com/blog/application-layer-ddos-attack-protection-with-haproxy)**

[2]

> [@Growing IP ACL file](https://discourse.haproxy.org/t/growing-ip-acl-file/6161/2):
>
> Updating a file and reloading, like you suggest, or: Updating a file (so that future reload/restarts have uptodate data), but instead of reloading haproxy you can add or remove entries via the admin socket: [https://cbonte.github.io/haproxy-dconv/2.2/management.html#9.3-add%20acl](https://cbonte.github.io/haproxy-dconv/2.2/management.html#9.3-add%20acl) When you run out of RAM. Blocking them in iptables (with ipsets) or the equivalent in nftables is probably even more efficient.

---

<div class="post-metadata">

**Author:** ![lukastribus](https://avatars.discourse-cdn.com/v4/letter/l/7ea924/32.png) [@lukastribus](https://discourse.haproxy.org/u/lukastribus)\
**Post date:** [February 4, 2021, 4:35pm UTC](https://discourse.haproxy.org/t/i-can-replace-iptables-ipset-with-acl-src-f/6216/2 "2021-02-04T16:35:45Z")

</div>

> [@f1outsourcing](#):
>
> `http-request deny if { src -f /etc/hapee-1.8/blacklist.acl }`

If you don’t care about a HTTP response, then it’s cheaper to abort the TCP connections:

```
tcp-request connection reject if ...

```

> [@f1outsourcing](#):
>
> I read some article that ipset had hardly any influence on the latency if it would contain ~50k entries.

Neither has haproxy.

> [@f1outsourcing](#):
>
> If specify in the file 1.1.4.0/24 and 1.1.4.1 will haproxy still process two lines or will 1.1.4.1 be disregarded?

There is no need to worry about it, it’s efficient enough. If you want your file to be aggregated, because a 100M file turns into a 500k file if you do, then you need to take care of it.

> [@f1outsourcing](#):
>
> Should this acl file be sorted?

No.

> [@f1outsourcing](#):
>
> Or does it not matter how ip addresses are in the file, because haproxy optimizes this when loaded into memory?

It doesn’t matter, haproxy can easily handle _a lot more_ than 50k and is only limited by your RAM.

> [@f1outsourcing](#):
>
> How much memory would a list of ~50k entries use?

I suggest you test it, I guess we are talking about a few MB. If you use multi-process mode (nbproc \> 1) - which you shouldn’t - then the RAM usage multiplies with each process of course.

> [@f1outsourcing](#):
>
> Is it better to just use one acl list for each service/frontend or is there next to no loss to use multiple, like this?

It’s fine.

> [@f1outsourcing](#):
>
> And a bit out of curiosity, how does blacklisting via acl’s compare to ipset in with added latency?

People run haproxy with millions of ACL entries in production. It’s extremely efficient and you have nothing to worry about.

---

<div class="post-metadata">

**Author:** ![f1outsourcing](https://avatars.discourse-cdn.com/v4/letter/f/a183cd/32.png) [@f1outsourcing](https://discourse.haproxy.org/u/f1outsourcing)\
**Post date:** [February 6, 2021, 11:50am UTC](https://discourse.haproxy.org/t/i-can-replace-iptables-ipset-with-acl-src-f/6216/3 "2021-02-06T11:50:53Z")

</div>

> [@lukastribus](#):
>
> > [@f1outsourcing](#):
> >
> > `http-request deny if { src -f /etc/hapee-1.8/blacklist.acl }`
> 
> If you don’t care about a HTTP response, then it’s cheaper to abort the TCP connections:
> 
> ```auto
> tcp-request connection reject if ...
> 
> ```

Is it possible to read these files in default and then reference them in the frontend section  
something like

defauls/global  
xxx blacklistweb src -f clouds.acl  
xxx blacklistweb src -f web.acl  
xxx blacklistweb src -f test.acl

frontend http  
mode http  
bind 0.0.0.0:80  
tcp-request connection reject if blacklistweb

---

<div class="post-metadata">

**Author:** ![lukastribus](https://avatars.discourse-cdn.com/v4/letter/l/7ea924/32.png) [@lukastribus](https://discourse.haproxy.org/u/lukastribus)\
**Post date:** [February 6, 2021, 12:03pm UTC](https://discourse.haproxy.org/t/i-can-replace-iptables-ipset-with-acl-src-f/6216/4 "2021-02-06T12:03:14Z")

</div>

It’s isn’t, as far as I know.