Bridge filter rules

Hi!

I have Mikrotik based on arm64 (12XS-2XQ). I’m setting up simple isolated network using a bridge with added interfaces.
RouterOS newest → 7.13.2 (stable)
I would like to filer out any traffic that could appear - now it is only DHCP Discovery from servers’ NICs.

I read about Bridge filter option, but cannot get it to work.
I have setup bridge to use:
Use IP Firewall → Enabled
Allow Fast Path → Enabled

And created filter rule:
Bridge → Filters:
Chain=input action=drop in-interface-list=stream bridge (but also is the same without this) mac-protocol=ip src-address=0.0.0.0/0 dst-port=67-68 ip-protocol=udp

That’s all.

I have counter of packets that are related to the rule → and it increases, so it looks like working.

However I’m checking the arrival traffic on one of the NICs by wireshark - and the packets are incoming there despite of the rule.
The amount of packets is the same as in counter in the filter.

How to have this option working? That would be the simplest for me in order to filter this traffic.

By the way - how is possible to disable support for ICMPv6? Can it be done also by filter rules on the bridge?

Thanks, best regards

What kind of traffic do you want to delete/block? Specifically 67-68 port? It can also be locked in the RAW section. It is not necessary to use Bridge-filter. Are you using default firewall settings?

AFAIK bridge filters (and firewall rules) only work if traffic passes CPU. As you’re probably aiming for HW offload (to see wirespeed operation), you’ll have to use switch ACLs. The model name you wrote is not complete and thus I can’t tell if its switch chip supports ACLs at all.

Is there a need to block such traffic? I haven,t seen in many configs, with this type of ruleset so just curious if its unique to a certain type of ISP setup?

Anav friend, sorry, I don’t really understand you. I asked the author of the topic why he wants to block this 67-68 port, etc.
You mean blocking these ports in RAW chain? For example, I do not block these ports additionally. I don’t know why the author came up with that. This is in no way related to the ISP.

Offtoipic: Anav, tell me, please, where is your excellent description “Defacto Default Firewall”?

Currently you can find an archived version of the “Defacto Default Firewall” thread here:
https://web.archive.org/web/20230524131930/https://forum.mikrotik.com/viewtopic.php?t=180838

Thank you very much for the answer!

/ip firewall address-list
add address=IP1  list=Admin  (desktop)
add address=IP2  list=Admin  (laptop)
add address=IP3  list=Admin  (smartphone)
add address=IP4 list=Admin  (wireguard IP  - assuming MT is a wg server for handshake)
/interface list
name=WAN
name=LAN
name=Manage

/Interface list members
add interface=‘trusted_subnet’ list=Manage
add interface=WG list=Manage
~ entries for LAN
~ entries for WAN

/ip firewall filter
{Input Chain}
(default rules to keep)
add action=accept chain=input comment=“defconf: accept established,related,untracked” connection-state=established,related,untracked
add action=drop chain=input comment=“defconf: drop invalid” connection-state=invalid
add action=accept chain=input comment=“defconf: accept ICMP” protocol=icmp
add action=accept chain=input comment=“defconf: accept to local loopback (for CAPsMAN)” dst-address=127.0.0.1
( admin rules )
add action=accept chain=input comment=“wireguard handshake” dst-port=WG_Listening_Port protocol=udp
add action=accept chain=input src-address-list=Admin comment=“Config Access”
add action=accept chain=input comment=“Allow LAN DNS queries-UDP” \ {and NTP *** services if required etc}
dst-port=53,123 in-interface-list=LAN protocol=udp
add action=accept chain=input comment=“Allow LAN DNS queries - TCP”
dst-port=53 in-interface-list=LAN protocol=tcp
add action=drop chain=input comment=“drop all else”
{forward chain}
(default rules to keep)
add action=accept chain=forward comment=“defconf: accept in ipsec policy” ipsec-policy=in,ipsec
add action=accept chain=forward comment=“defconf: accept out ipsec policy” ipsec-policy=out,ipsec
add action=fasttrack-connection chain=forward comment=“defconf: fasttrack” connection-state=established,related
add action=accept chain=forward comment=“defconf: accept established,related, untracked” connection-state=established,related,untracked
add action=drop chain=forward comment=“defconf: drop invalid” connection-state=invalid
(user rules)
add action=accept chain=forward comment=“allow internet traffic” in-interface-list=LAN out-interface-list=WAN
add action=accept chain=forward comment=“allow dst-nat from both WAN and LAN (including port forwarding)” connection-nat-state=dstnat
add action=drop chain=forward comment=“drop all else”
/ip firewall nat
add action=masquerade chain=srcnat comment=“defconf: masquerade” ipsec-policy=out,none out-interface-list=WAN

/ip neighours discovery
…interface-list=MANAGE

//tool mac-server mac-winbox
set allowed-interface-list=MANAGE

Hi!

First of all thank you for so many replies in such short time!

Answering the questions :
@johnson73 - in general I want to block everything issued by NICs in “automatic way” in a broadcast manner - like DHCP client requests etc. I think this is called BOOTSP (bootstrap) on both IPv4 and IPv6. I’m checking the result just by wireshark on one of the interfaces is there is nothing received.

I have all of the firewall switched off (cleared). In general I would like to have minimal CPU load by such filtering (not affecting routing speed). That’s exactly as @mkx underlined.

Just to give some more description. This network is a completely isolated/local network for streaming tests only. I’m streaming custom protocol and due to simplicity of implementation I want to block any other packets that is not related to the stream (so that my hardware and applications wouldn’t retransmit such packets). I think @mkx you really got my idea :wink: I want to exactly trace the wire-speed operation. The minimal CPU load I think would be necessary with those rules → I would be generating about 80Gbps traffic (50Gbps TX and 40Gbps RX) around the ports in bridge configuration (and later maybe more). That’s why I don’t put any special config. And routing will be based on ARP table only (Layer 2 routing).

@mkx The full model is: CCR2216-1G-12XS-2XQ . Btw - I didn’t know about this switching option (ACL) - is it also capable of (for example) DSC_MAC swapping or other “on the go” modifications in Layer 2?

Due to description from what I read the Bridge filter have less CPU load than using IP Firewall (I don’t know if RAW is the same in this case?).

By the way, in the mean time I’m found some presentation that was describing, that this kind of filtering (bridge level) can be only done with HW offload switched OFF. I have checked this and the filter started to working.
However, this maybe affect the streaming performance (relating to @mkx maximum wirespeed)? Now I tested on only 10Gbps on TX on one port.

@anav - I think the description above mostly explains the necessity of the filtering. I could also do it on each server separately, however just again for simplicity I wanted to try to do it more “central” in simple way - but maybe this is much less efficient than disabling this in each NICs configuration?

Thanks! Best regards

Hi there, thanks for the feedback.
I am actually more interested not in the mechanics but WHY?
Is it a useful thing, or an extra that most dont need?

The 2116 is a POWERFUL router so its not like you have to save CPU cycles.
I usually focus on what traffic is needed for my users and devices, I dont focus on blocking anything at all because I use a DROP ALL concept.
At the end of the input chain and forward chain (keeping good default rules) I make only a few rules to allow necessary traffic and
the LAST rule in each chain is:
add chain=forward action=drop comment=“drop all else”

This mean NO traffic passes that I didnt explicitly state was allowed. Thus I dont understand the concept of trying to block traffic as a focus point instead of focussing on needed traffic.

Thus asking the WHY.
What are you afraid of?
Is there an attack vector we dont know about?

You mentionned this is related to servers. Are these rules to ensure the servers do something different from normal servers?
For example what is the requirement (or use case). Ex. The servers should have fixed static LANIP and not get DHCP… etc…

A look at official test results reveals that CPU is realistically not capable of passing more than around 40Gbps (give or take). Or even less if frames used are small.
One of (hard) bottlenecks is also interconnect between switch chip and CPU (4x25Gbps which is not exactly the same as 1x100Gbps).

So you really want to use switch ACLs instead of bridge filters. I don’t have such device, so I can’t help you with ACL particularities. You may want to start another thread with title which would attract people with ACL experience.

Since you’re going to use your CCR as a switch, a (carefully chosen) CRS3xx would likely be a better choice price wise with same performance levels. Some CRS3xx are beasts when it comes to switching, they only lack CPU power which you can’t utilize anyway.

Thanks again for the replies.

@anav Due to specifics of the laboratory setup, random traffic (I think mostly broadcast traffic) cannot reach specific ports, since it will get retransmitted by those ports. And at the end I’m doing a comparison between reference data and retransmitted by the specific ports so I don’t want any extra data added in “random” places. So for me is a useful thing in a way that I’m doing this only on switch, and not on each node individually (by reconfiguring each NIC). In production environment this won’t be used at all.

The “nodes” and servers are very simple in term of configuration, don’t use DHCP, ARP - in fact nothing. In final use case this will be a point-to-point connection between two devices.
I’m testing the custom frames with unused Ethertype.

Thank you very much for mentioning the concept of accept and after drop everything else. I really like I and understand how this can be nicely adapted.

However, getting to @mkx answer - I really need a high throughput - thank you for linking the tests! I’m using maximum frames - jumbo 9000. So this setup, as I understand, cannot use any type of rules → either Firewall IP (but I’m not using IP), or RAW or Bridge Filter since this all would go to CPU, since it looks like total (sum of TX and RX) continuos stream of around 90Gbps can be too much with Firewall filtering.

However, interesting point - there is a row → bridge with none rules at 1500bytes frame - this gives almost ~80gbps traffic. This I understand is routing by switch chip only? I’m a bit surprised by that → for example running the movie on the website of this model → around 2:44 shows table with Bridge speed of 200+Gbps using 1500bytes frames (??).
Here is the same: datasheet

Because now I’m wondering if I’m on the limit of the switching just by the streaming… I thought this can easily switch much more than 200Gbps.

Thanks to you both again for the support!
Best regards

Nope, that’s still bridging via CPU. Proper switches have in their test results additional section: switching. That one is for switch-chip performance. For example: CRS309.

Your CCR, whcih is supposed to be a router, doesn’t include such section in test results. But it’s a common knowledge that this particular device uses very decent switch chip (which can do wirespeed L3 routing; the last test result line in routing section says so) and foundation for L3 switching is … well, switching. So if L3HW routing indicates anything, then it indicates that your CCR should be able to do at least (cumulative) 200Gbps switching.