Isolate two bridges at Layer 2

RouterOS General
1

Hello
On a CCR2004, I have two bridges. Bridge_A which has sfp1 to sfp5 and Bridge_B which includes sfp6 to sfp10. Internet is configured on ether1.
I want to isolate the two bridges, don’t want them to talk to each other at Layer2, while the two bridges need to access internet.
What is the best way to achieve this without disabling hardware offload?
Thank you.

2

How the two bridges, talk each other at Layer 2 ? Give an example? What a connection they have?

3

Now that you’re asking I think I made a dumb question. The bridges, being logical interfaces, act like normal interfaces, so there should be no L2 talk between them, right?

4

I think so . You can isolate them if they have IP addresses for example, but this is Layer 3 !

5

Correct. Once you add IP addresses to each bridge then IP traffic at layer 3 can route between them unless blocked with firewall rules.

Regarding a point in your original post, I don’t believe the CCR2004 has hardware offloading so having multiple bridges is not an issue. Devices which do, e.g. CRS3xx, only support hardware offloading on one bridge.

6

Correct regarding bridges - they are like separate interfaces. They have nothing common between them so no L2 routing between them is possible if you did not setup any exotic configurations.

Instead you should probably use this:

add action=drop chain=forward in-interface=bridge1 out-interface=bridge2
add action=drop chain=forward in-interface=bridge2 out-interface=bridge1
7

You don’t need this because by default they are 2 virtual switches that work on 2 L2 Broadcast domains. So concept “L2 Routing” is wrong!

8

Whereas the term “L2 routing” is indeed confusing and misleading, the OP may need the IP firewall rules suggested, to prevent traffic between the two subnets from being delivered via L3. It doesn’t matter how exactly the traffic leaks between them (L2 or L3), it matters that it does at all.

I personally strongly prefer the reverse firewall concept (drop everything by default, accept only exceptions), but other people may have different preference.

9

I have encountered a strange issue. I have two Bridge devices, configured with the addresses 192.168.11.1/24 and 192.168.22.1/24, each with a DHCP server. Now, without any NAT rules configured, devices in the 192.168.11.1/24 network can directly access devices in the 192.168.22.1/24 network. What could be the problem?

10

The fact that hosts (devices) in two distinct subnets connected to the same router can communicate to each other is not a “problem” but a basic functionality of a router. I assume your DHCP servers assign 192.168.11.1 and 192.168.22.1 as the default routes in their respective subnets, so a device in 192.168.11.0/24 sends packets for any other destination than 192.168.11.0/24, including 192.168.22.0/24, to the router, and the router finds a route, which in case of destination 192.168.22.0/24 is the other bridge, and forwards the packet.

If you want to prevent this, use the rules in the ip firewall filter table. As the rules in firewall are a kind of a program where the effect of each single rule depends at least on the previous rules in the same chain, it is not possible to suggest anything more specific before seeing the export of your current configuration. Remove sensitive information (passwords, public addresses, usernames to external services, serial number, …) before posting the export.

11

My firewall’s Filter rules are as shown in Mikrotik’s First Time Configuration example. There is only one NAT rule: perform srcnat masquerade on the output interface named isp-internet. I assume that with this configuration, the network should behave as follows:

  1. The 192.168.11.1/24 network and the 192.168.22.1/24 network should be like two separate, unconnected switches, unable to access each other directly. If cross-network access is needed, masquerade should be configured.
  2. Both the 192.168.11.1/24 and 192.168.22.1/24 networks should be able to access the internet through the masquerade rule on the isp-internet.

However, the current situation is very strange:

  1. The 192.168.11.1/24 network, the regular internal network, can access the internet and the 192.168.22.1/24 network without masquerade configured.
  2. Devices on the 192.168.22.1/24 network cannot access the internet, nor devices on the 192.168.11.1/24 network; they can only access other devices on the same Bridge.

I want to know what the issue is.

12

The issue with 1. is that you misunderstand masquerade to do something else than it really does. The purpose of masquerade is to hide the private addresses, which are not unique in the internet so tens of thousands of devices in the world have the same address 192.168.11.10, and make sure that the servers on public addresses will know where to send responses to requests coming from clients on private addresses. So as the client request packet passes through the WAN interface, its source address gets changed to the one of the WAN interface, and the addreses and ports as well as the new address are stored in a table of a connection tracking module, so when the response from the server arrives, it can be linked to such a known connection and its destination address can be changed to the private one of the cllient that has sent the initial request. Since requests from 11.x to 22.x are not routed via WAN, the masquerade rule ignores them.

The issue with 2. is that the “First Time Configuration” example assumes that you start with no firewall rules in the router, but most SOHO routers are shipped with a default configuration, which seems to be your case, otherwise you could get to internet from 192.168.22.0/24 as well - the masquerade rule from the First Time Configuration nor the one from the factory default configuration cares about src-address or in-interface. So there must be some other rule that prevents connections initiated by clients in 192.168.22.0/24 from getting anywhere at all.

References to configuration suggestions/manual pages says nothing about the actual configuration of your device. If you post your configuration export, the issue can be identified and clarified in minutes, otherwise it’s just guessing.

13

This is my detailed configuration:

2024-07-21 15:48:57 by RouterOS 7.15.2

software id =

/interface bridge
add name=iotbridge // IoT devices only, 192.168.22.1/24
add name=local // normal devices, 10.0.0.1/16

Internet connection provided by ISP

/interface pppoe-client
add add-default-route=yes disabled=no interface=ether9 name=ct user=[redacted]

vlan encapsulation for a certain interface, allowing multiple logical lines in one physical connection

/interface vlan
add interface=ether8 name=iot vlan-id=40
add interface=ether8 name=iptv vlan-id=10
add interface=ether8 name=sip vlan-id=20

create two bridges, one for normal devices, the other for IoT devices

/interface bridge
add bridge=iotbridge comment=“iot downlink” interface=iot // IoT devices will be attatched to this bridge
add bridge=iotbridge comment=“iot uplink” interface=ether10 // HomeAssistant virtual machine

/interface bridge port
add bridge=local comment=inteth interface=ether1
add bridge=local comment=25g interface=ether4
add bridge=local comment=1g interface=ether6

/ip address
add address=10.0.0.1/16 interface=local network=10.0.0.0
add address=192.168.22.1/24 interface=iotbridge network=192.168.22.0

/ip pool
add name=dhcp_pool0 ranges=10.0.0.2-10.0.255.254
add name=dhcp_pool1 ranges=192.168.22.2-192.168.22.254

/ip dhcp-server
add address-pool=dhcp_pool0 comment=internet interface=local lease-time=10m name=dhcp1
add address-pool=dhcp_pool1 comment=iotnetwork interface=iotbridge name=dhcp2

/ip dhcp-server network
add address=10.0.0.0/16 dhcp-option=domain-searchlist dns-server=10.0.0.3 gateway=10.0.0.1
add address=192.168.22.0/24 gateway=192.168.22.1

/interface list
add comment=lan name=lan

/interface list member
add comment=“local switch” interface=local list=lan

/ip firewall filter
add action=accept chain=input comment=“accept established,related” connection-state=established,related
add action=accept chain=input comment=“accept ICMP” in-interface=ct protocol=icmp
add action=drop chain=input comment=“drop invalid” connection-state=invalid
add action=drop chain=input comment=“block everything else” in-interface-list=!lan
add action=accept chain=forward comment=“accept established,related” connection-state=established,related
add action=drop chain=forward comment=“drop invalid forward” connection-state=invalid
add action=drop chain=forward comment=“drop access to clients behind NAT from WAN” connection-nat-state=!dstnat
connection-state=new in-interface-list=!lan
add action=drop chain=forward comment=“drop everything else” in-interface-list=!lan

/ip firewall nat
add action=masquerade chain=srcnat comment=“internet nat” out-interface=ct

/routing igmp-proxy interface
add interface=iptv upstream=yes
add interface=ether2

Any comments will be appreciated!

14

Leaving other things aside (we may get to them later), and concentrating only on the issue with the two bridges, I would suggest to add the following rules to the end of the forward chain of /ip firewall filter:
add chain=forward in-interface=local out-interface=ct action=accept
add chain=forward in-interface=iotbridge out-interface=ct action=accept
add chain=forward action=drop
To make those additional rules actually work, the next step is to disable (and once you check that the setup actually does what you want it to do, remove) the currently last “drop everything else” rule in chain forward.

15

I got it! The last rule means “drop all that not coming from 10.0.0.0/16”, that blocks 192.168.22.1/24 from connecting to the main network. So, by default, different bridges on one RouterOS can visit each other, right? I need to add firewall filters manually to isolate those bridges?

16

Basically, you did get it. There are subtle nuances - e.g. src-address, src-address-list, in-interface, and in-interface-list can all be used to identify the source of a traffic, but each of them is better suitable for another particular scenario. So speaking strictly, the last rule of your original config does not care about any address but indeed about in-interface no matter what the source address is. But the understanding why and how use of precise terms helps thinking about things will come with more experience.

17

Thanks a lot!