Isolate two bridges(subnets) firewall

Hello.
Why “drop forward” doesnt block connection between bridges(subnets), anyway I can ping each other? It blocks WAN(NAT), but doesnt block inner connection between subnets. Firmware the newest, router ax2. I have tried different options, but just left most primitive, just to understand where is the problem.
Config:

# 2023-10-13 22:08:39 by RouterOS 7.11.2

# model = C52iG-5HaxD2HaxD

/interface bridge
add admin-mac=B6:A7:6A:0F:36:6C auto-mac=no comment=LAN name=bridge1
add admin-mac=EE:BD:94:AC:2B:0F auto-mac=no comment=LAN-WIFI name=bridge2
/interface list
add name=LAN
/ip pool
add name=dhcp_pool0 ranges=10.1.0.200-10.1.0.254
/ip dhcp-server
add address-pool=dhcp_pool0 interface=bridge1 lease-time=1h name=dhcp1
/interface bridge port
add bridge=bridge1 interface=ether3
add bridge=bridge1 interface=ether4
add bridge=bridge2 interface=ether5
/interface list member
add disabled=yes interface=bridge1 list=LAN
add disabled=yes interface=bridge2 list=LAN
/ip address
add address=10.1.0.1/24 interface=bridge1 network=10.1.0.0
add address=10.2.0.1/24 interface=bridge2 network=10.2.0.0
/ip dhcp-client
add interface=ether1
/ip dhcp-server network
add address=10.1.0.0/24 dns-server=10.1.0.1 gateway=10.1.0.1
/ip dns
set allow-remote-requests=yes servers=1.1.1.1
/ip firewall filter
add action=drop chain=forward connection-state=""
/ip firewall nat
add action=masquerade chain=srcnat

Because your drop rule has connection-state=“” … but no connection state is equal empty string and hence no packet matches the rule. Setting something to empty string is not the same as not setting it.

Unset the property entirely (if using GUI, click the up-arrow so that it “folds”).

As said before I have tried everything and just forgot to remove field of states. Anyway ping goes between bridge1 and bridge2.

set allow-remote-requests=yes servers=1.1.1.1
/ip firewall filter
add action=drop chain=forward

Reply from 10.2.0.1: bytes=32 time<1ms TTL=64
Reply from 10.2.0.1: bytes=32 time<1ms TTL=64
Reply from 10.2.0.1: bytes=32 time<1ms TTL=64
Reply from 10.2.0.1: bytes=32 time<1ms TTL=64

Ping statistics for 10.2.0.1:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 0ms, Maximum = 0ms, Average = 0ms

Pinging router’s “non-native” address is actually handled by “chain=input” just like if pinging “native” address. And don’t go into “but that’s not right” argument, that’s the way it is and has been since forever.

Im here not to arguing but to understand where is the problem because before to write here I have tried to config according to manual/video, where bridge blocking was in forward drop.
Can you show exactly rule how to block bridge connection? Or can you link me to article where I can to read it.

Only one Firewall filter entry is visible from your copied configuration. Why? Where are the other rolls?
To isolate access to two different Brides, you must first use “default rules”, where you will also create the necessary entries.
I would recommend using the following method -

/ip firewall filter
{Input Chain}
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 in-interface-list=LAN
add action=drop chain=input comment="drop all else"
{forward chain}
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
add action=accept chain=forward comment="allow internet traffic" in-interface-list=LAN out-interface-list=WAN
add action=accept chain=forward comment="allow 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" out-interface-list=WAN

Local_Lan=(your local IP address Bridge1)
Local_Lan2=(your local IP address Bridge2)
LAN= Bridge1
LAN2-=Bridge2
This rule - add action=accept chain=forward comment=“allow internet traffic” in-interface-list=LAN out-interface-list=WAN
=is responsible for ensuring that, for example, “Bridge1” has access to the Internet.
If you create another roll for “Bridge2”, then you will write accordingly -
→ add action=accept chain=forward comment=“allow internet traffic” in-interface-list=LAN2 out-interface-list=WAN

In this configuration, both Bridges will be isolated. If there is a need, for example, to access from Bridge1 to Bridge2, then you will have to create an additional rule=
add action=accept chain=forward comment=Lan-Access dst-address-list=Local-LAN2 src-address-list=Local-LAN…

As I wrote: your issue is not about blocking traffic between two bridges, it’s about (IMO cosmetic) issue of connecting router’s “non-native” address. To verify that your forward filter rule actually does the job, you have to use two devices, connected to different bridges, and try ping (or any other traffic) between those.

The basic packet flow is this: router receives packet, it checks if DST NAT needs to be performed (if yes, dst-address and optionally dst-port get replaced). Then it inspects dst-address (in case of DST NATed packets again). If (the new) dst-address matches any of router’s own addresses (ingress interface doesn’t matter), then packet is handled by chain=input. The rest of packets (which will eventually egress router via another L3 interface) are handled by chain=forward. Every packet is only handled by one of basic chains (forward, input or output - this one handles packets originating from router itself).


Now, if you want to block the non-native connectivity to router, you can add something like this:

/ip firewall filter
add chain=input action=drop dst-address=10.1.0.1 in-interface=!bridge1
add chain=input action=drop dst-address=10.2.0.1 in-interface=!bridge2

(note the “!” in front of interface names … it means “not ”).

Keeping in mind that every firewall chain has implicit last rule with action=accept, it would be easier (safer, more restrictive … name it whatever you want) to change the above to

/ip firewall filter
add chain=input action=accept dst-address=10.1.0.1 in-interface=bridge1
add chain=input action=accept dst-address=10.2.0.1 in-interface=bridge2
add chain=input action=drop

Any other necessary (accept) rules would go above the last (unconditional) drop rule.