MikroTik

Hi everyone,

Can anyone verify? I have a drop all input rule but as you can see in the screenshot, traffic destined for ff02::1 still slips through. You can see this in the upper window "Packet Sniffer Packets". Moreover, the 2nd rule blocking traffic destined for ff02::1 is not hit. This is normal as ALL packets should have been stopped by the first rule.

If I swap rule 0 and rule 1 it still does not block them despited the packet count going up for the rule blocking traffic to ff02::1.

Packet sniffer see everything. IMHO. It work on lower level than IP stack.

Firewall rule is wrong. You droping packet on input, but packets are TX (output).

Packet sniffer see everything. IMHO. It work on lower level than IP stack.

Firewall rule is wrong. You droping packet on input, but packets are TX (output).

The rule matches, so what is your reasoning behind it being wrong? Most sniffers work by passing the packets up to the CPU. If that does not happen (like with fast forwarding in Cisco) the CPU won't see the packet and the sniffer (probably tcp dump for Mikrotik) won't either. Learned that the hard way:-)

Try to drop output; it seems to be skipping forward, and I think if the router originates the packets, it will place directly at output chain.

Mikrotik is not Cisco. Mikrotik doesn't have hardware routing, doesn't have ASIC chip. Mikrotik is software router based on Linux. Everything going to CPU (except L2 configurations on switch chip).
Packet sniffer is tcpdump (or similar sw). Working in promiscuous mode - see everything in network (directly from NIC driver).
After that packet going to IP stack - and to netfilter rules.

Netfilter has three basic chains: input, forward, output. Input chain see packets that ending on this router. Output chain see packets that leaves router (packets created in router). And forward see packet going through router (everything else).

Mikrotik is not Cisco. Mikrotik doesn't have hardware routing, doesn't have ASIC chip. Mikrotik is software router based on Linux. Everything going to CPU (except L2 configurations on switch chip).
Packet sniffer is tcpdump (or similar sw). Working in promiscuous mode - see everything in network (directly from NIC driver).
After that packet going to IP stack - and to netfilter rules.

Netfilter has three basic chains: input, forward, output. Input chain see packets that ending on this router. Output chain see packets that leaves router (packets created in router). And forward see packet going through router (everything else).

Thanks you are correct. I do believe Mikrotik has a fast chain. I do not know if this influences the sniffer. At any rate, I do not have that enabled so this is just a fyi.

So as an update:I have now sniffed on the first device connected to the RB. It's a Netgear switch. I mirrored the port on the Netgear that is connected to the RB. And I can see packets destined to ff02::1 there. So the drop rule IS matching but the RB is not dropping the packets. Still looks like a bug.

A bridge filter for dropping packets to 33:33:xx:xx:xx:xx does work. So on L2 I can block the IPv6 multicast.
See screenshot in attach. You can see 2 rules 1)for blocking IPv4 broadcast and 2) for blocking IPv6 multicast

Try to drop output; it seems to be skipping forward, and I think if the router originates the packets, it will place directly at output chain.

Packets come in from the WAN-BRIGDE (this bridge contains the WAN interface uplink to a cable modem and it also contains VLAN20). By the way, it is a CASA CMTS that is the source of the multicast traffic to ff02::1.

I can see this traffic on every switch that has VLAN20 on it. So that is why I want to drop it at the Mikrotik RB. Point is, that I only see it on the input chain. Not on the output nor on the forward chain.
It's probably because of the bridge that contains VLAN20? As you can see in my previous post, I can block the traffic using a filter rule in at the bridge. I cannot block it using the IPv6 firewall rule although the rules matches, the packet sails right through.