7 ;;; Accept all from WAN established, related
chain=input action=accept connection-state=established,related in-interface=bridge-WAN log=no
pass incoming ICMP requests to my router from external IPs? How come that it treats them as established or related?
If I add the following rule BEFORE that one, my router stops responding to external ICMP requests
6 ;;; drop ICMP from WAN
chain=input action=drop protocol=icmp in-interface=bridge-WAN log=yes log-prefix="DROP-WAN-ICMP--"
But if I put this "drop ICMP’ rule AFTER the “allow established, related” all incoming ICMP traffic is processed by the rule #7 and my router becomes pingable from outside
I don’t care about other people’s asspain because of my router not responding on their ping request, sorry.
But still… just out of the academic interest, I’m very curious why this is happening with ICMP traffic
OP is right. Incoming ICMP packets from not related and not established connection should not be matched by that rule. My only assumption is that the connection is established (e.g. previously accepted pings) or related (e.g. some other connection between IP addresses).
It definitely should not accept ICMP echo requests from any random IP unless there is explicit “accept ICMP” rule.
If you have already ping for test from something, the connection tracking consider subsequent ping as estabilished,
if you move the drop rule after estabilished, you must purge connection tracking or wait grace period.
If you have some remote control over another connection to do test, ping from that source are considered related.
The ICMP are not only used for ping, but for useful Path MTU Discovery.
The real pain in the ass is that you «both» do not know that.
If you have already ping for test from something, the connection tracking consider subsequent ping as estabilished,
Yes, That is my assumption that OP didn’t notice existing connection and rule got matched thanks to that. Otherwise it would be serious bug. I reacted only because previous answers from you and anav sound as if the “accept established+related” rule should indeed match any ICMP, including non-established/related, which just does not make sense to me.
The real pain in the ass is that you «both» do not know that.
That was not necesary, was it? I am merely trying to sort out possible misunderstanding which is clearly happening here.
6 ;;; drop ping requests from WAN
chain=input action=drop tcp-flags="" protocol=icmp in-interface=ether1-WAN icmp-options=8:0-255 log=no
I remain unpingable but all other ICMP stuff is untouched.
But there’s still something to play with regarding the original question and it goes deeper. What is actually an ESTABLISHED connection? How does router decide to mark a packet as established? I got the general point - due to some other connections or another similar packets that were accepted previously. But what’s the timeout for that? How similar the other packets should be?
This is a reply for what have wrote @TANDR
You forgot to add “The ICMP are not only used for ping, but for useful Path MTU Discovery” on quote.
Without that part, it loses meaning.
Is considered estabilished for the time set inside ip / firewall / connections / tracking
Is estabilished if LAN send something outside to an IP.
Until the timeout for that event do not happen, every reply is considered estabilished, subsequent packets must not pass again on firewall,
and any other connections incoming from that IP, not part of main estabilished connection, are considered related,
like incoming SIP call, just for example, the phone is already registered on another estabilished connection, and the incoming call is a related connection,
and also those packets must not be filtered from firewall.
Speaking of ICMP, there are some strange things that I cannot address on my RB5009 / 7.3.1 (and it was with other 7.x releases also)
I was logging all ICMP on the INPUT-chain and see thousands & thousands of these passing by.
So why is this Mikrotik issuing “Type 3 , Code 1” messages from itself to itself ?
Type 3 = Destination Unreachable
Code 1 = Port Unreachable
All these interface are VLAN L3 192.168.x.x “IP interfaces” of LAB-segments and perfectly reachable for example…very weird.
The 192.168.1.254 = Wireguard segment
Don’t have any netwatch/monitoring thing active.
Well if you consider “Wireguard” to be an IPIP-tunnel that that would only account for 192.168.1.254 (=L3 interface “wireguard1” interface)
All others are just IP’s belonging to VLAN’s under a Bridge-interface.
Interesting to know anyway, not really an issue, it just caught my eye.
Interesting find, that current ICMP rule does not have any IN or OUT “interface-list” applied, everything is left “blanc”
The moment I edit the rule and put “all” … suddenly the logging of these hits STOPS
Now just below this rule there is default DENY on anything on the INPUT-chain.When I disable my custom ICMP-rule suddenly my DEFAULT IN DROP start showing these ICMP-loggings.
The last DROP-rule also does not have “all” field populated at the in-interfaces-list field.
Sooo … I always believed there was no difference between using “all” interfaces-list and just not putting anything in there “blanco” … but behaviour is different.
The moment I put “all” on this rule in the IN “interface-list” field, this excessive logging goes away…
I’ve checked with CLI too, remains the same. In the past some Winbox config ends up differently on the box then using pure CLI…
Like the RouterOS documentation described
There are three predefined lists - all (contains all interfaces), none (contains no interfaces) and dynamic (contains dynamic interfaces). It is also possible to create additional interface lists.
