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?
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.
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 rc.local:
This is generally not recommended. Instead, here’s a set of iptables rules for a more nuanced setup (to be placed in firewall.local):
i#!/bin/sh
# Used for private firewall rules
# See how we were called.
case "$1" in
start)
## 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
;;
stop)
## 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
;;
reload)
$0 stop
$0 start
## add your 'reload' rules here
;;
*)
echo "Usage: $0 {start|stop|reload}"
;;
esac
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?
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.
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.
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.
