Disable the ping response on the red interface?

I just decided to give ipfire a try to replace the aging smoothwall setup we had (since smoothwall isn’t updating it anymore). I too am looking for a way to disable the ping response on the red interface (or on the whole system). Smoothwall had this option in the web interface that disabled a icmp respons for all the interfaces, and I know ipfire is distantly derived from smoothwall. So I would imagine that ipfire had the option at one time. Why was it removed?

There are good reasons to drop/ignore the pings as many others have pointed out. If you don’t specifically need anything to respond to a ping, they should be ignored. And I want them to be.
Anyway, where can I put in a request to have the option added back into the interface so it is that simple again? I don’t want to start messing with config files and commands, it used to be simple…

Firewall rule? :slight_smile:
I use ping as a way to monitor if the connection is capable of responding, for remote devices. I whitelisted ping from the ip addresses involved in monitoring.

As discussed in several threads, inhibiting ICMP responses doesn’t real help.
Pinging an IP can result in three kinds:

  • ‘NOT REACHABLE’, the last router/gateway can’t reach the client. Client not existent/active
  • no answer, client is reachable/existent but doesn’t respond
  • deny, similiar
1 Like

Hello @gilligan, welcome to our community. I’ve seen that the topic of ICMP (Internet Control Message Protocol) has attracted a lot of attention in our discussions. While the decision to disable or enable ICMP can be subjective, let’s look at some facts that suggest a more balanced approach may be beneficial.

Essential ICMP Types:

  • Echo Request and Echo Reply (Type 8 and Type 0): These are used by the ping command, a staple tool for network diagnostics.

  • Fragmentation Needed (Type 3, Code 4): Vital for Path MTU Discovery, this enables two hosts to determine the smallest MTU size that can be used between them. Blocking it can result in traffic being “black-holed” and a subsequent degradation in TCP/IP performance.

  • Time Exceeded (Type 11, Code 0): This type is utilized by traceroute to identify each hop between hosts. Without it, troubleshooting becomes far more complicated.

A Balanced Approach:

While it’s possible to disable ICMP entirely in IPFire with the following command in

echo "net.ipv4.icmp_echo_ignore_all = 1" >> /etc/sysctl.conf 
sysctl -p

This is generally not recommended. Instead, here’s a set of iptables rules for a more nuanced setup (to be placed in firewall.local):

# Used for private firewall rules

# See how we were called.
case "$1" in
        ## add your 'start' rules here
        iptables -A CUSTOMINPUT -p icmp -i red0 --icmp-type 0 -j ACCEPT
        iptables -A CUSTOMINPUT -p icmp -i red0 --icmp-type 3 -j ACCEPT
        iptables -A CUSTOMINPUT -p icmp -i red0 --icmp-type 11 -j ACCEPT
        iptables -A CUSTOMINPUT -p icmp -i red0 --icmp-type 8 -m limit --limit 1/second -j DROP
        iptables -A CUSTOMINPUT -p icmp -i red0 -j DROP
        ## add your 'stop' rules here
        iptables -D CUSTOMINPUT -p icmp -i red0 --icmp-type 0 -j ACCEPT
        iptables -D CUSTOMINPUT -p icmp -i red0 --icmp-type 3 -j ACCEPT
        iptables -D CUSTOMINPUT -p icmp -i red0 --icmp-type 11 -j ACCEPT
        iptables -D CUSTOMINPUT -p icmp -i red0 --icmp-type 8 -m limit --limit 1/second -j DROP
        iptables -D CUSTOMINPUT -p icmp -i red0 -j DROP
        $0 stop
        $0 start
        ## add your 'reload' rules here
        echo "Usage: $0 {start|stop|reload}"

This configuration allows essential ICMP types while rate-limiting echo requests to once per second. The idea is not to eliminate ICMP traffic, but to manage it in a way that ensures both security and necessary functionality.

It’s important to note as remarked by @bbitsch that blocking ICMP Echo Replies (Type 0) doesn’t necessarily make your network invisible or more secure. If a machine simply drops Echo Requests and doesn’t reply, the absence of an Echo Reply itself can indicate that a machine is present and is filtering packets. In standard networking, when a host is genuinely unreachable, the router or gateway usually sends an ICMP Destination Unreachable message (Type 3, Code 1). Therefore, experienced users may interpret the lack of such a message as a sign that a machine is actively filtering ICMP, thus tipping them off to the machine’s presence.

Overall, configuring ICMP filtering should strike a balance between security and network functionality. My opinion is leaning toward the latter.


@jon @bbitsch @bonnietwin Can we place what I wrote (if you agree on the content) in the wiki and point to the page next time this issue is raised again?

1 Like

@cfusco , no problem.
I think your statement gives a good overview about ICMP traffic.

1 Like

Hi all,
@cfusco as an beneath information,i would also delete the rules or flush CUSTOMINPUT in “stop)” section in firewall.local to prevent duplicates of the same rules.



1 Like

Thank you all for the quick responses! And cfusco, you gave a great explanation about icmp.
I guess I was hopeful for a simple checkbox like what smoothwall had. Oh well, I don’t want to mess with config files right now. But if I do in the future, I can refer back to this thread now.
I also didn’t think of the idea that a lack of a response could be interpreted as something being there, so maybe it isn’t worth the trouble anymore anyway.
So far I am very happy with ipfire. Seems like it is the perfect replacement for our old smoothwall router.
Thank you all again.


You are absolutely right. I have update the example code.

A short version can be

        ## add your 'stop' rules here
        iptables -F CUSTOMINPUT

but may also good to list them all with the -D flag to make things more clear.



1 Like

@jon if you have no objection, where can we put this howto in the wiki?

A good place would be in wiki.ipfire.org - Tutorials and Learning Material for Newbies.
But this is mainly a page of links.
Another place could be the examples section of wiki.ipfire.org - Firewall Documentation.

1 Like

@bbitsch wiki.ipfire.org - ping


@cfusco , thx.
I’ve added a link to wikipedia. This rounds up the information for the interested user.:wink:


There is an extraneous “i” at the start of the sample firewall.local file on the wiki.

# Used for private firewall rules
1 Like

Corrected. :slight_smile:


The wiki placement looks good. Please add “not recommended” paragraph as the first paragraph.

I remember having problems with OpenVPN and it would not work with ping disabled. This was more than 5 years ago. I use IPSec these days so I dont know if this is still an issue.

I think Peter (or one of the Core Devs) wrote a Post about why disabling ping was a bad idea. I don’t remember if this was a Community post or a Dev List post…




Thank you @jon for your help. I’ve updated the wiki article to prominently feature the “not recommended” warning as the first paragraph, underscoring the general consensus against disabling ICMP.

The introduction has also been restructured to strongly advocate for the importance of maintaining network functionality. While my personal views strongly align with preserving ICMP, I’ve retained the technical details for those who opt to disable pings. This approach ensures that the article remains a comprehensive resource for everyone, irrespective of their stance on the issue.

Feel free to further intensify the language if you think it’s necessary.


I did not see this on the ping wiki page… maybe it did not save?!?

i don’t know what happened. Now it should be there.