[HELP] The right rules for "ShieldUP" positive test

Hello IPFire community,
I’m enjoying this firewall and I’m learning how to improve the strength of it.
I have some troubles by configuring the right rules to achieve a positive analysis in “ShieldUP!”, but every time is a failed test (port closed instead of “stealth” and some of these result open)

The rules I’m thinking to use are:

  1. TCP 80,443 GREEN to FIREWALL (a sort of anti lock out from IPFire web interface)
  2. ICMP Type 3,8 GREEN to ALL
  3. ICMP 0,3,11 ALL to GREEN
  6. REJECT DNS requests from other sources
  7. TCP 21,80,443 GREEN to ALL
  8. TCP 465,993,995 GREEN to RED
  9. TCP\UDP 49152-65535 GREEN to ALL

Someone can help me by “hardening” my firewall? What I’m doing wrong?
Many thanks :slight_smile:

When I ran ShieldsUP! I only found one item open and it was ping. Everything else was Stealth.

Ping Reply: RECEIVED (FAILED) — Your system REPLIED to our Ping (ICMP Echo) requests, making it visible on the Internet.

I am curious: Are you really getting all of these items as open on ShieldsUP??

Also, If you plan to use OpenVPN don’t block all types of ICMP. It will cause problems with OpenVPN. I don’t know about IPsec.

In “Firewall Options”, are “Firewall policy” set to “DROP”? That’s “stealth”, in Gibson terminology. If set to “REJECT” it will generate blue boxes in the test.

Blocking ping has little effect. You will be port scanned anyway, and if you have any port open, you will be detected. No matter; it’s just a part of internet life.

Neither OpenVPN nor IPSec, to my knowledge, need ICMP to work. There are sometimes ping options to keep connections open, but that’s traffic to internal IPs, not the external IPs of VPN endpoints.

When I set a firewall rule to block all pings, the IPFire OpenVPN server continually reset the connection ever 60 seconds (may have been 30 seconds). I had to delete the rule.

That’s not any sort of OpenVPN limitation I know of. I am right now connected to an OpenVPN server (granted this is not IPFire) where the endpoint does not allow ping (the UDP port is forwarded to an internal OpenVPN server), and that connection has been open for more than two hours without issue.

However, there are options to ping-restart the connection in the way you describe, but these should be used only for internal IPs.

Hi Marco, I remember in te old forum I asked for blocking the ICMP, and I still remember that @ms told me how, but sadly I can’t get to that old forum and I can’t find a hint for that nider on my pc.

If it’s a way to get to the old forum from ipfire i am shure you could find it.

But I think this link would help you:

I think its the same thing that Michael Tremmer told me long ago.

Sins that time my ipfire is full stealth on grc.com.

Best regards,

Sharlon ( Neopegasus)

Don’t believe that you are invisible if you block ICMP. If you block it the attacker get no answer which indicate that you exist, because with a not existing IP the router before your ip will answer with an error message. So even if you drop ICMP you will detected.

Blocking ICMP create other problems such long timeouts or breaking connections. ICMP is also used to
determine the optimal packet size so blocking it is dumb.


Now you let me :thinking: thinking, I remember I did something like on the link I shared, I think was some pro and cons to do it, as I know you’re (@arne_f ) also one of the dev of ipfire.

What would someone like @marcvs do/learn from this kind of website?

I did that in my beginning of ipfire to because the router that my ipfire replace was doing it to.

Now a day, that setting is somewhere in my backup I am guessing :thinking: as I did that once, and in all the updates and problems that I had, I never needed to did it again…

Or are we missing something?

Happy new year :confetti_ball:

Best regards


It will only be in your backup if you added /etc/sysctl.conf
to your /var/ipfire/backup/include.user file.

Whether it stays there or not during any Core Updates will depend on the changes made in the Core Update. As sysctl is related to setting kernel parameters during run time it could be possible that kernel changes might result in the file being set back to standard as part of the update.


Exactly, that’s why I am thinking :thinking:, because that means, why if I didn’t change or adjust it, ipfire is still stealth when i do the same test and @marcvs don’t?

There’s where @arne_f let me start thinking!

I am not a someone that likes/love to do things in the kernel lvl and if I do it, i mostly forget to do it after a update.

When i did that was long before we have community.ipfire.org, it was in time of forum.ipfire.org ( the old forum) so its before 2018 wich for sure now is my kernel default again…

1 Like

If you really want block ping you should add

iptables -A CUSTOMINPUT -i red0 -p icmp --icmp-type echo-request -j DROP
to the start and
iptables -D CUSTOMINPUT -i red0 -p icmp --icmp-type echo-request -j DROP
to the stop section in /etc/sysconfig/firewall.local
(replace red0 by ppp0 if you not use a ppp dialup connection)
and set “Default behaviour of (input) firewall” to drop in firewall options then this tests will passed.