# IPS Whitelist not working

**URL:** <https://community.ipfire.org/t/ips-whitelist-not-working/7347>\
**Category:** Intrusion Prevention\
**Created:** [2 March 2022 11:43 UTC](https://community.ipfire.org/t/ips-whitelist-not-working/7347 "2022-03-02T11:43:40Z")\
**Posts on this page:** 11\
**Page:** 1

<div class="post-metadata">

**Author:** ![briand](https://community.ipfire.org/user_avatar/community.ipfire.org/briand/32/4551_2.png) [@briand](https://community.ipfire.org/u/briand)\
**Post date:** [2 March 2022 11:43 UTC](https://community.ipfire.org/t/ips-whitelist-not-working/7347/1 "2022-03-02T11:43:41Z")

</div>

I am having difficulty with the functionality of “Whitelisted Hosts” in the IPS. For example, IPS rules are triggered for ICMP \*NIX and show 2 IP addresses. If I enter these IP addresses as Whitelisted Hosts, the rule still triggers and the traffic is dropped/blocked - I would have expected this traffic to now be allowed. To allow the traffic I have to disable the rule. Has anyone else had issues like this or can offer any suggestions? Note that one of the addresses is the Green interface of IPFire itself ie I’m trying to ping IPFire from a linux box.

---

<div class="post-metadata">

**Author:** ![rejjysail](https://community.ipfire.org/user_avatar/community.ipfire.org/rejjysail/32/15539_2.png) [@rejjysail](https://community.ipfire.org/u/rejjysail)\
**Post date:** [2 March 2022 21:11 UTC](https://community.ipfire.org/t/ips-whitelist-not-working/7347/2 "2022-03-02T21:11:02Z")

</div>

Hi @briand  
I seem to recall a similar issue on core 161 which was blocking Covid-19 related traffic. I had set up a whitelist of ip addresses the official sites that i needed to connect to, and appeared to not work at first.

However, if i recall correctly (memory not so good ☹ , I believe that after doing a Apply Change to the firewall rules (not full sure about that step), i did do a reboot and the changes appear to have worked.

---

<div class="post-metadata">

**Author:** ![pmueller](https://community.ipfire.org/user_avatar/community.ipfire.org/pmueller/32/9019_2.png) [@pmueller](https://community.ipfire.org/u/pmueller)\
**Post date:** [3 March 2022 09:42 UTC](https://community.ipfire.org/t/ips-whitelist-not-working/7347/3 "2022-03-03T09:42:40Z")

</div>

Hi,

> [@rejjysail](#):
>
> I seem to recall a similar issue on core 161 which was blocking Covid-19 related traffic.

that was probably due to some hunting rules - I remember those triggering on some of my installations as well… 🙂

It looks like we should really clarify in the [documentation](https://wiki.ipfire.org/configuration/firewall/ips) if the whitelist refers to the source of a connection, the destination, or both. To be honest, I am not sure about that myself currently… 😑

Will check and report back.

Thanks, and best regards,  
Peter Müller

---

<div class="post-metadata">

**Author:** ![briand](https://community.ipfire.org/user_avatar/community.ipfire.org/briand/32/4551_2.png) [@briand](https://community.ipfire.org/u/briand)\
**Post date:** [3 March 2022 10:09 UTC](https://community.ipfire.org/t/ips-whitelist-not-working/7347/4 "2022-03-03T10:09:38Z")

</div>

Thanks guys - I have tried source, destination and both. Will investigate further and try a reboot. If it is a host do I simply enter the ip address or do I need a /32 at the end ?

---

<div class="post-metadata">

**Author:** ![rejjysail](https://community.ipfire.org/user_avatar/community.ipfire.org/rejjysail/32/15539_2.png) [@rejjysail](https://community.ipfire.org/u/rejjysail)\
**Post date:** [4 March 2022 13:37 UTC](https://community.ipfire.org/t/ips-whitelist-not-working/7347/5 "2022-03-04T13:37:08Z")

</div>

Not sure about the subnet masking (eg /32).  
In my case i was just entering the IP addresses of the websites my browser was trying to access (aka destinations).

---

<div class="post-metadata">

**Author:** ![pmueller](https://community.ipfire.org/user_avatar/community.ipfire.org/pmueller/32/9019_2.png) [@pmueller](https://community.ipfire.org/u/pmueller)\
**Post date:** [22 March 2022 09:45 UTC](https://community.ipfire.org/t/ips-whitelist-not-working/7347/6 "2022-03-22T09:45:08Z")

</div>

Hi,

first, sorry for my tardy reply on this. 😑

Adding `/32` is not necessary for whitelisting a single IP address.

Generally speaking, it is currently not possible to ignore a certain IPS rule for certain IP addresses. We [discussed implementing this in February](https://wiki.ipfire.org/devel/telco/2022-02-07), but it’s not an easy job to do, and resources are currently needed elsewhere.

Therefore, I am afraid you will either have to disable the IPS rule completely, or whitelist the client triggering it for the entire IPS.

Sorry to disappoint, and best regards,  
Peter Müller

---

<div class="post-metadata">

**Author:** ![scaredycrow](https://community.ipfire.org/user_avatar/community.ipfire.org/scaredycrow/32/4724_2.png) [@scaredycrow](https://community.ipfire.org/u/scaredycrow)\
**Post date:** [26 April 2022 01:47 UTC](https://community.ipfire.org/t/ips-whitelist-not-working/7347/7 "2022-04-26T01:47:21Z")

</div>

> Therefore, I am afraid you will either have to disable the IPS rule completely, or whitelist the client triggering it for the entire IPS.

For clarification, does this mean a DESTINATION address may not be whitelisted currently?

That would explain some behaviour I’m currently troubleshooting.

---

<div class="post-metadata">

**Author:** ![pmueller](https://community.ipfire.org/user_avatar/community.ipfire.org/pmueller/32/9019_2.png) [@pmueller](https://community.ipfire.org/u/pmueller)\
**Post date:** [26 April 2022 11:23 UTC](https://community.ipfire.org/t/ips-whitelist-not-working/7347/8 "2022-04-26T11:23:42Z")

</div>

Hi,

unfortunately, yes.

A fix is already available but requires some more QA, so it will be included in Core Update 168 ([Core Update 167](https://blog.ipfire.org/post/ipfire-2-27-core-update-167-is-available-for-testing) is scheduled for release tomorrow).

Sorry for all the inconvenience, and best regards,  
Peter Müller

---

<div class="post-metadata">

**Author:** ![scaredycrow](https://community.ipfire.org/user_avatar/community.ipfire.org/scaredycrow/32/4724_2.png) [@scaredycrow](https://community.ipfire.org/u/scaredycrow)\
**Post date:** [5 September 2022 01:29 UTC](https://community.ipfire.org/t/ips-whitelist-not-working/7347/9 "2022-09-05T01:29:35Z")

</div>

Hi @pmueller, I would like to close the loop on this topic.

It appears now on Core 169 that a whitelisted IP address (in my case a public destination IP address on the internet) is indeed bypassing all Suricata scanning, which would be expected yes?

---

<div class="post-metadata">

**Author:** ![trish](https://community.ipfire.org/user_avatar/community.ipfire.org/trish/32/16001_2.png) [@trish](https://community.ipfire.org/u/trish)\
**Post date:** [5 September 2022 19:22 UTC](https://community.ipfire.org/t/ips-whitelist-not-working/7347/10 "2022-09-05T19:22:45Z")

</div>

Hi Josh, no not a public IP,

I think a whitelisted IP address is your local IP address, example 192.168.1.2 or 10.0.2.2 etc…  
Basicaly, if Suricata is blocking your PC or device you can just bypass ALL Suricata rules for that PC, device, client etc

If you are familiar with firewalls, it is sort of like putting a local IP in a “DMZ”

---

<div class="post-metadata">

**Author:** ![scaredycrow](https://community.ipfire.org/user_avatar/community.ipfire.org/scaredycrow/32/4724_2.png) [@scaredycrow](https://community.ipfire.org/u/scaredycrow)\
**Post date:** [6 September 2022 01:38 UTC](https://community.ipfire.org/t/ips-whitelist-not-working/7347/11 "2022-09-06T01:38:57Z")

</div>

Appreciate the response trish. What I’m seeing that led to my post, is that right now if I have a connection that is not ‘allow listed’ I see Suricata consuming a reasonable % of CPU when I stress that connection.

After allow listing, the CPU load to that connection goes away.

This is all positive from my perspective as it’s the desired behaviour.
