I’m having problems blocking ICMP (echo-reply) packets from WAN. Below are my firewall filters for your reference, the one which I specifically did is rule #5.
[admin@MikroTik] /ip firewall filter> print
Flags: X - disabled, I - invalid, D - dynamic
0 D ;;; special dummy rule to show fasttrack counters
chain=forward action=passthrough
1 ;;; defconf: fasttrack
chain=forward action=fasttrack-connection connection-state=established,related log=no log-prefix=“”
2 ;;; defconf: accept established,related
chain=forward action=accept connection-state=established,related log=no log-prefix=“”
3 ;;; defconf: drop invalid
chain=forward action=drop connection-state=invalid log=no log-prefix=“”
4 ;;; defconf: drop all from WAN not DSTNATed
chain=forward action=drop connection-state=new connection-nat-state=!dstnat in-interface=ether1 log=no log-prefix=“” 5 chain=input action=drop protocol=icmp in-interface=ether1 icmp-options=8:0 log=no log-prefix=“”
6 chain=input action=accept protocol=icmp log=no log-prefix=“”
7 chain=input action=accept connection-state=established log=no log-prefix=“”
8 chain=input action=accept connection-state=related log=no log-prefix=“”
9 chain=input action=drop in-interface=pppoe-out1 log=no log-prefix=“”
Thanks in advance, your help is highly appreciated.
Ether1 in your case is merely physical interface carrying packets encapsulated into PPPoE. Your wan interface is pppoe-out1 and you should use that interface in FW rules that protect your router from evil internet.
As to firewall: you’re blocking echo-reply … meaning that if you use ping tool on your router to ping some WAN host, your FW will drop reply. What you probably want is to block echo(-request), which, according to RFC792, is icmp-options=8:8 …
This should be relatively easy.
In my default setup I have this rule.
/ip firewall filter
add action=accept chain=input comment=“defconf: accept ICMP” protocol=icmp
I am assuming the input accept rule is there because otherwise the incoming traffic will be dropped by
one of the following rules…
add action=drop chain=input comment=“defconf: drop invalid” connection-state=
invalid
add action=drop chain=input comment=“defconf: drop all not coming from LAN”
in-interface-list=!LAN
I suppose one could add in a specific rule to drop but is probably no needed.
In which case take the same rule and simply change this to drop!! and place it at after all the accept rules for input.
Chain= input
protocol= 1 (ICMP)
action= drop
The question I have is why not put it as an IP RAW rule in prerouting???
and thus it will be removed before getting any kind of connection.
Thanks for the suggestion anav, if im mistaken already did this with no success but will have a look again.
As for this being easy, i totally agree with you but for some strange reason its not working. Ichecked various tutorials and all suggested the same rule i implemented however ping request are still being answered.
Anyway if you insist on it start with simple input icmp drop rule placed somewhere on top. If this works then do fine tuning in more detail.
If this does not work then you are actually pinging different device (you modem - as you wrote that your WAN is ether1). Therefore switch your modem to bridge and create PPPoE client in Mikrotik. And be careful /clever with firewall rules (your WAN will be pppoe1 now!)
Why?
If there is a default rule to allow ICMP on the input chain. Removing the rule should be all that is required.
If there is need to block ICMP, why not do it in IP RAW in prerouting.
Nobody is listening LOL.
Here are my replies; @Pea: I want to disable ICMP from WAN for security reasons. I know there are other ways one can identify if there is something active on a particular public IP but I would like to minimize this as possible.
@CZFan: I will try your suggestion and revert back, however, the strange thing is that I disabled all those rules listed in the attached file, yet my public IP still replies from outside. @anav: Could you please guide me how to block implement via suggested IP RAW prerouting?
Hi FoxJr,
I just tested my Filter Rules from default.
I had the allow ICMP rule in there…
I checked my ports via www.grc.com and the shieldsUP tests.
I failed as the ICMP replies occurred from my router.
I removed the rule and I passed the test
Your system ignored and refused to reply to repeated Pings (ICMP Echo Requests)
So I disagree with your findings!
The default Filter rules already block ICMP, I had to put in an allow rule to make myself visible.
/ip firewall filter
add action=accept chain=input comment=
“defconf: accept established,related,untracked” connection-state=
established,related,untracked add action=accept chain=input comment=“defconf: accept ICMP” protocol=icmp
add action=drop chain=input comment=“defconf: drop invalid” connection-state=
invalid
add action=drop chain=input comment=“defconf: drop all not coming from LAN”
in-interface-list=!LAN
Although I dont have any output rules and forward chains should not affect wan responses I put them here just in case…
add action=drop chain=forward comment=“defconf: drop invalid”
connection-state=invalid
add action=drop chain=forward comment=
“defconf: drop all from WAN not DSTNATed” connection-nat-state=!dstnat
connection-state=new in-interface-list=WAN
Finally If I was to make a raw rule, which I don’t think is necessary it would look something like
/ip firewall raw
add action=drop chain=prerouting protocol=icmp comment=Stop_Ping in-interface ISPname OR (in-interface list WAN if you have dual ISP, wan1 and wan2)
Hey guys, thanks for your feedback. Unfortunately, I had no time to review or test any suggestions due to busy schedule. Will do this in the following days and revert back with results.
Are you sure it is not maybe your device 192.1682.109 responding to pings, see last rule in ip firewall nat, you are forwarding everything coming in on PPPoE to that device
Change this “add action=drop chain=forward comment=“defconf: drop all from WAN not DSTNATed” connection-nat-state=!dstnat connection-state=
new in-interface=ether1” on pppoe-out1 in in-interface, please.
4 ;;; defconf: drop all from WAN not DSTNATed
chain=forward action=drop connection-state=new connection-nat-state=!dstnat in-interface=pppoe-out1 log=no log-prefix=“”
No luck, still able to ping from an external source.
