How to blocking bridge traffic on L2?

mrmut · Sat Jun 01, 2019 2:55 pm

I am using specific bridges for MikroTik CAPsMan WiFi and LAN, and the idea is to block traffic between the two.

I tried

/interface bridge filter
add action=drop chain=forward in-bridge=WiFi out-bridge=LAN

And nothing. I the rule doesn't see any traffic thru the bridge, while I can clearly see traffic from WiFi-LINK to INTERNET when I try speedtest for isntance.

I also tried Firewall, on IP level:

/ip firewall filter
add action=reject chain=forward in-interface=WiFi out-interface=LAN reject-with=icmp-net-prohibited

Any ideas?

Local forwarding and Client to client forwarding is turned off.

sindy · Sat Jun 01, 2019 6:36 pm

You must have built some deep misunderstanding of the internal L2 architecture (and yes, the names of the match conditions in-bridge and out-bridge easily contribute to that as they are neither intuitive nor well-explained in the documentation). A bridge filter rule always acts on a single bridge because the frames never pass from one bridge to another one at L2 (except via /interface vlan but even in that case the /interface bridge filter rules act on a single bridge at a time, even though the same rule may act at several bridges if there is no match condition linking the rule to a particular bridge or interface). So you say you want to block traffic between LAN and WiFi bridges, but then you take as a proof that none of the rules work the fact that you can see traffic from WiFi to get to internet, whereas in typical topologies such traffic does not have to pass through another LAN and goes to WAN directly.

Normally, when you split wired and wireless LAN to two distinct bridges, you have one IP subnet hosted on bridge LAN, and another subnet hosted on bridge WiFi. So your rule in /ip firewall would prevent clients connected to WiFi from establishing connections to servers connected to LAN (but not vice versa!), but would not affect connection to internet from clients connected via either of the bridges.

Too much information is missing to say what is actually wrong, so post your configuration following the hint in my automatic signature below.

mrmut · Sun Jun 02, 2019 10:42 pm

Thank you very much for you help. I read what I could for MikroTik, but as this is not my primary focus it is hard to grasp it all.

I probably (certainly) was not very clear; I have CAPsMAN that is routing WiFi to the internet on separate bridges (two of them), and I wanted to filter them out. If I use IP filter for filter out subnets, would that cut off other communication in that case? Broadcast and such?

On another setup I have two physical bridges for which I filter traffic by simply setting:

add action=reject chain=forward in-interface=bridge-1 out-interface=bridge-2 reject-with=\
    icmp-net-prohibited

For some reason that doesn't work in CAPsman case.

Here is the export you asked in the sig. Thanks!

# jun/02/2019 21:24:44 by RouterOS 6.43.16
# software id = NKA5-NKSP
#
# model = RB750Gr3
# serial number = 8AFF098A1409
/caps-man channel
add comment="Auto channel reselect period" name=RESELECT reselect-interval=1h
/interface bridge
add name=INTERNET
add name=LAN-COMPANY
add name=WiFi-GOSTI
add name=WiFi-COMPANY
add name=WiFi-LINK
/interface ethernet
set [ find default-name=ether1 ] name=ether1-WAN speed=100Mbps
set [ find default-name=ether2 ] name=ether2-1KAT speed=100Mbps
set [ find default-name=ether3 ] name=ether3-PROIZVODNJA speed=100Mbps
set [ find default-name=ether4 ] name=ether4-MRKVA speed=100Mbps
set [ find default-name=ether5 ] name=ether5-MACMINISERVER speed=100Mbps
/caps-man configuration
add channel.extension-channel=disabled datapath.bridge=WiFi-COMPANY mode=ap \
    name=COMPANY security.authentication-types=wpa2-psk security.encryption=\
    aes-ccm ssid=COMPANY
add datapath.bridge=WiFi-GOSTI mode=ap name=GUESTS \
    security.authentication-types=wpa2-psk security.encryption=aes-ccm ssid=\
    GUESTS
add channel.extension-channel=disabled datapath.bridge=LAN-COMPANY mode=ap name=\
    LINK security.authentication-types=wpa2-psk security.disable-pmkid=yes \
    security.encryption=aes-ccm ssid=LINK
/interface list
add name=KPK-LAN
/interface wireless security-profiles
set [ find default=yes ] supplicant-identity=MikroTik
/ip hotspot profile
set [ find default=yes ] html-directory=flash/hotspot
/ip pool
add name=lan-COMPANY-pool ranges=192.168.0.40-192.168.0.240
add name=wifi-COMPANY-pool ranges=192.168.10.2-192.168.10.254
add name=wifi-gosti-pool ranges=192.168.20.2-192.168.20.254
/ip dhcp-server
add address-pool=lan-COMPANY-pool disabled=no interface=LAN-COMPANY lease-time=\
    1w1d name=lan-COMPANY-dhcp
add address-pool=wifi-gosti-pool disabled=no interface=WiFi-GOSTI lease-time=\
    12h name=wifi-gosti-dhcp
add address-pool=wifi-COMPANY-pool disabled=no interface=WiFi-COMPANY lease-time=\
    1w1d name=wifi-COMPANY
/caps-man manager
set ca-certificate=auto certificate=auto enabled=yes package-path=\
    /microSD/capsman upgrade-policy=suggest-same-version
/caps-man manager interface
add disabled=no interface=LAN-COMPANY
add disabled=no forbid=yes interface=INTERNET
/caps-man provisioning
add action=create-dynamic-enabled master-configuration=COMPANY name-format=\
    prefix-identity name-prefix=CAP slave-configurations=LINK,GUESTS
/interface bridge filter
add action=passthrough chain=forward disabled=yes in-bridge=WiFi-GOSTI \
    out-bridge=INTERNET
add action=passthrough chain=forward disabled=yes in-bridge=INTERNET \
    out-bridge=WiFi-GOSTI
/interface bridge port
add bridge=LAN-COMPANY hw=no interface=ether2-1KAT
add bridge=LAN-COMPANY hw=no interface=ether3-PROIZVODNJA
add bridge=LAN-COMPANY hw=no interface=ether4-MRKVA
add bridge=LAN-COMPANY hw=no interface=ether5-MACMINISERVER
add bridge=INTERNET interface=ether1-WAN
/interface bridge settings
set use-ip-firewall=yes
/interface list member
add interface=LAN-COMPANY list=KPK-LAN
/ip address
add address=192.168.0.10/24 interface=LAN-COMPANY network=192.168.0.0
add address=192.168.20.1/24 interface=WiFi-GOSTI network=192.168.20.0
add address=192.168.10.1/24 interface=WiFi-COMPANY network=192.168.10.0
/ip dhcp-client
add dhcp-options=hostname,clientid disabled=no interface=INTERNET
/ip dhcp-server network
add address=192.168.0.0/24 caps-manager=192.168.0.10 dns-server=\
    192.168.0.10,192.168.0.1 domain=kpk.local gateway=192.168.0.10 ntp-server=\
    192.168.0.10
add address=192.168.10.0/24 dns-server=192.168.10.1 gateway=192.168.10.1 \
    ntp-server=192.168.10.1
add address=192.168.20.0/24 dns-server=192.168.20.1 gateway=192.168.20.1 \
    ntp-server=192.168.20.1
/ip dns
set allow-remote-requests=yes servers=176.103.130.130,176.103.130.131
/ip firewall address-list
add address=192.168.0.2-192.168.0.254 list=allowed_to_router
add address=192.168.42.2-192.168.42.254 list=allowed_to_router
/ip firewall filter
# in/out-bridge-port matcher not possible when interface (WiFi-GOSTI) is not slave
# in/out-bridge-port matcher not possible when interface (LAN-COMPANY) is not slave
add action=passthrough chain=forward in-bridge-port=WiFi-GOSTI out-bridge-port=\
    LAN-COMPANY
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=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
add action=drop chain=forward comment=\
    "defconf:  drop all from WAN not DSTNATed" connection-nat-state=!dstnat \
    connection-state=new in-interface=INTERNET
/ip firewall nat
add action=masquerade chain=srcnat comment=MASK ipsec-policy=out,none \
    out-interface=INTERNET
/ip service
set telnet disabled=yes
set ftp disabled=yes
set api disabled=yes
set api-ssl disabled=yes
/ip ssh
set strong-crypto=yes
/system clock
set time-zone-name=Europe/Zagreb
/system identity
set name="MAIN ROUTER"
/system ntp client
set enabled=yes primary-ntp=216.239.35.0 secondary-ntp=216.239.35.4
/system package update
set channel=long-term
/system resource irq rps
set ether1-WAN disabled=no
set ether2-1KAT disabled=no
set ether3-PROIZVODNJA disabled=no
set ether4-MRKVA disabled=no
set ether5-MACMINISERVER disabled=no
/tool graphing
set store-every=hour
/tool graphing interface
add
/tool graphing queue
add
/tool graphing resource
add
/tool mac-server
set allowed-interface-list=none
/tool mac-server ping
set enabled=no

sindy · Sun Jun 02, 2019 11:51 pm

I read what I could for MikroTik, but as this is not my primary focus it is hard to grasp it all.

Mikrotik or networking as a whole?

I probably (certainly) was not very clear

I to je to zašto je potreban export, jer iz njega se vidi sve.

I have CAPsMAN that is routing WiFi to the internet on separate bridges (two of them), and I wanted to filter them out. If I use IP filter for filter out subnets, would that cut off other communication in that case? Broadcast and such?

And this is the point. Broadcasts only work within an L2 domain, routers never forward broadcast packets across the border of a subnet. So a broadcast received at one bridge interface is only delivered to member ports of that same bridge, including the local one of the Mikrotik (which is a "hidden" port of the bridge). Multicast packets can be forwarded between L2 domains but only if such forwarding is subscribed to, and it is not used on the internet, only in private networks.

So when you want your WiFi clients to be able to talk to servers in the internet, you don't need to be afraid of blocking of forwarding of broadcast and multicast packets outside from their bridges - these are not forwarded by design.

Regarding filtering of traffic flow between bridges: packets between two different subnets must be routed, not bridged, even if the two subnets were hosted on the same bridge (which is not your case). You use a distinct subnet on each of your three bridges, so to prevent delivery of packets from one subnet to another, you have to prevent them from being routed, not bridged. To do that, you need ip firewall filter rules which have to say "packets coming from 192.168.20.0/24 can be forwarded to any destination except 192.168.0.0/24 and 192.168.10.0/24", or "packets coming in via interface (not bridge-interface) WiFi-GOSTI can be forwarded to any outgoing interface except LAN-COMPANY and WiFi-COMPANY." as you did in the other setup you've mentioned.

You use the default setup of the firewall on Mikrotik which basically says "permit everything, drop exceptions". So 1) whatever passes through the forward chain's last rule saying "drop all from WAN not DSTNATed" is accepted, and 2) packets belonging to already established connections are permitted in both directions thanks to the third and fourth rule in the forward chain, saying "fasttrack or accept whatever matches connection-state=established. So if you add a rule
chain=forward action=drop in-interface=WiFi-GOSTI out-interface=LAN-COMPANY,
it will prevent clients connected to the guest WiFi from initiating connections to devices in your LAN (but not to the Mikrotik itself), but it will not prevent devices in your LAN from initiating connections to clients connected to the guest WiFi. To do that, you need another drop rule where the values of in-interface and out-interface are swapped.
To prevent clients of guest WiFi from accessing Mikrotik's own management, you need a rule
chain=input action=drop in-interface=WiFi-GOSTI protocol=tcp dst-port=22,23,80,443,8291,8728-8729 at the end of your current chain=input.
I suppose the Mikrotik gets a private IP on the INTERNET interface from an ISP's router; if it gets a public one, your firewall is far too weak and you need to add a couple more rules to it.

Also, you don't need use-ip-firewall in /interface bridge settings to be set to yes; in your current configuration it only wastes CPU but does nothing useful.

On another setup I have two physical bridges for which I filter traffic by simply setting:
Code: Select all
add action=reject chain=forward in-interface=bridge-1 out-interface=bridge-2 reject-with=\
    icmp-net-prohibited
For some reason that doesn't work in CAPsman case.

Correct, but that's not an /interface bridge filter rule, it is an /ip firewall filter rule. So you did it right there but for some reason you changed the approach here.

mrmut · Mon Jun 03, 2019 10:43 am

I read what I could for MikroTik, but as this is not my primary focus it is hard to grasp it all.
Mikrotik or networking as a whole?

Well I guess both? I read several books on MikroTik and networking, and did a lot of pondering thru the system.

I probably (certainly) was not very clear
I to je to zašto je potreban export, jer iz njega se vidi sve.

Hvala

I have CAPsMAN that is routing WiFi to the internet on separate bridges (two of them), and I wanted to filter them out. If I use IP filter for filter out subnets, would that cut off other communication in that case? Broadcast and such?
And this is the point. Broadcasts only work within an L2 domain, routers never forward broadcast packets across the border of a subnet. So a broadcast received at one bridge interface is only delivered to member ports of that same bridge, including the local one of the Mikrotik (which is a "hidden" port of the bridge). Multicast packets can be forwarded between L2 domains but only if such forwarding is subscribed to, and it is not used on the internet, only in private networks.

So when you want your WiFi clients to be able to talk to servers in the internet, you don't need to be afraid of blocking of forwarding of broadcast and multicast packets outside from their bridges - these are not forwarded by design.

Regarding filtering of traffic flow between bridges: packets between two different subnets must be routed, not bridged, even if the two subnets were hosted on the same bridge (which is not your case). You use a distinct subnet on each of your three bridges, so to prevent delivery of packets from one subnet to another, you have to prevent them from being routed, not bridged. To do that, you need ip firewall filter rules which have to say "packets coming from 192.168.20.0/24 can be forwarded to any destination except 192.168.0.0/24 and 192.168.10.0/24", or "packets coming in via interface (not bridge-interface) WiFi-GOSTI can be forwarded to any outgoing interface except LAN-COMPANY and WiFi-COMPANY." as you did in the other setup you've mentioned.

You use the default setup of the firewall on Mikrotik which basically says "permit everything, drop exceptions". So 1) whatever passes through the forward chain's last rule saying "drop all from WAN not DSTNATed" is accepted, and 2) packets belonging to already established connections are permitted in both directions thanks to the third and fourth rule in the forward chain, saying "fasttrack or accept whatever matches connection-state=established. So if you add a rule
chain=forward action=drop in-interface=WiFi-GOSTI out-interface=LAN-COMPANY,
it will prevent clients connected to the guest WiFi from initiating connections to devices in your LAN (but not to the Mikrotik itself), but it will not prevent devices in your LAN from initiating connections to clients connected to the guest WiFi. To do that, you need another drop rule where the values of in-interface and out-interface are swapped.
To prevent clients of guest WiFi from accessing Mikrotik's own management, you need a rule
chain=input action=drop in-interface=WiFi-GOSTI protocol=tcp dst-port=22,23,80,443,8291,8728-8729 at the end of your current chain=input.
I suppose the Mikrotik gets a private IP on the INTERNET interface from an ISP's router; if it gets a public one, your firewall is far too weak and you need to add a couple more rules to it.

Thanks this helps a lot. I deleted all rules pertaining to bridge filtering in bridge and firewall, and simply blocked un-needed subnets, solved router access thru
explicit allow IP list in "allowed_to_router", and alloed DNS queries. This does seem to be a working setup, is there something else I should pay attention to? ->

/ip firewall filter
add action=accept chain=input comment="defconf: accept established,related,untracked" connection-state=established,related,untracked
add action=accept chain=input comment="Allow IP range" src-address-list=allowed_to_router
add action=accept chain=input comment="ALLOW LOCAL TCP DNS IN" dst-port=53 in-interface=!INTERNET protocol=tcp
add action=accept chain=input comment="ALLOW LOCAL UDP DNS IN" dst-port=53 in-interface=!INTERNET protocol=udp
add action=drop chain=input comment="Disallow other" log=yes log-prefix="DROP ALL OTHER"
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=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
add action=drop chain=forward comment="defconf:  drop all from WAN not DSTNATed" connection-nat-state=!dstnat connection-state=new in-interface=INTERNET
add action=reject chain=forward comment="Block WiFi-COMPANY" dst-address=192.168.0.0/24 reject-with=icmp-net-prohibited src-address=192.168.10.0/24
add action=reject chain=forward comment="Block WiFi-GOSTI" dst-address=192.168.0.0/24 reject-with=icmp-net-prohibited src-address=192.168.20.0/24

Also, you don't need use-ip-firewall in /interface bridge settings to be set to yes; in your current configuration it only wastes CPU but does nothing useful.

Thanks. Deleted all of the rules there.

Regarding the public firewall; any suggestions what I should improve? A link to a good resource would suffice; I will dig in.

sindy · Mon Jun 03, 2019 6:17 pm

Regarding the public firewall; any suggestions what I should improve? A link to a good resource would suffice; I will dig in.

Well... as this response silently admits that you were running the machine on a public IP for a while with remote access to management ports open, I would strongly recommend to do a complete export of the configuration (without hide-sensitive) into a file, download that file to your PC, and then netinstall the machine and restore the configuration from that export (after checking for existence of some scripts or enabled /ip socks in it and eventually fixing that) before connecting it back to internet. Multiple people have reported inability to upgrade a machine the normal way, where the upgrade file just disappeared after the reboot but the version remained the same, so there is a suspicion that some malware can survive a normal upgrade whereas a netinstall rewrites the flash completely.

As for your rules for separation of LANs, you prevent clients in both company WiFi and guest WiFi from talking to hosts in wired LAN, but you don't prevent them from talking to each other. Is that an intention or an omission?

Just a remark, in the input chain of the filter some other rules follow the "drop the rest" one. These other rules will never do anything as the "drop the rest" one never lets any packet reach them. The purpose of "drop invalid" is covered by "drop the rest" so no harm there; however, "accept icmp" may have been moved behind the "drop the rest" by mistake? As thing stands now, you cannot ping your router's WAN IP from the internet.

What's your primary specialization (given that networking is a secondary one now

)?

mrmut · Sat Jun 08, 2019 1:10 pm

Well... as this response silently admits that you were running the machine on a public IP for a while with remote access to management ports open, I would strongly recommend to do a complete export of the configuration (without hide-sensitive) into a file, download that file to your PC, and then netinstall the machine and restore the configuration from that export (after checking for existence of some scripts or enabled /ip socks in it and eventually fixing that) before connecting it back to internet. Multiple people have reported inability to upgrade a machine the normal way, where the upgrade file just disappeared after the reboot but the version remained the same, so there is a suspicion that some malware can survive a normal upgrade whereas a netinstall rewrites the flash completely.

Thanks for a tip, but how do you mean open? I have specific IP range defined as allowed to input, and MAC server is only allowed from LAN interfaces?
(The file was not complete, I was working on it.)

As for your rules for separation of LANs, you prevent clients in both company WiFi and guest WiFi from talking to hosts in wired LAN, but you don't prevent them from talking to each other. Is that an intention or an omission?

TBH I really don't care much about WiFi clients, there are only phones there, and may they do what they want. If they would eat BW too much, I would implement rule to limit them.
However, as for client to client communication, no need to do that in Firewall, AFAIK, as I have client to client forwarding turned off. At least that is how I presume it works?

Just a remark, in the input chain of the filter some other rules follow the "drop the rest" one. These other rules will never do anything as the "drop the rest" one never lets any packet reach them. The purpose of "drop invalid" is covered by "drop the rest" so no harm there; however, "accept icmp" may have been moved behind the "drop the rest" by mistake? As thing stands now, you cannot ping your router's WAN IP from the internet.

Thanks a lot for ICMP! I haven't noticed that one. Fixed it!

What's your primary specialization (given that networking is a secondary one now )?

Well, I am a molecular biotechnologist by training, however I never really worked in the field. - I make and maintain computer systems for small and medium (in modest terms) companies. While I am pretty sure I don't do everything perfect, I try my best. One has to realize it is not possible to everything perfectly. The current LAN I built has 11 devices; 1 router, 4 CAPs, 3 PoE switches and 4 regular ones, everything 5p. It is not a large network, but works nicely. Had to do it this way, because they didn't want to invest into structural cabling, so I worked around it. My largest network has about 50 devices in it.

sindy · Sat Jun 08, 2019 2:11 pm

(The file was not complete, I was working on it.)

This information was missing, hence my suggestion.

As for your rules for separation of LANs, you prevent clients in both company WiFi and guest WiFi from talking to hosts in wired LAN, but you don't prevent them from talking to each other. Is that an intention or an omission?

However, as for client to client communication, no need to do that in Firewall, AFAIK, as I have client to client forwarding turned off. At least that is how I presume it works?

The "client to client forwarding" setting is only relevant for clients using the same SSID, i.e. where the wireless stack of the AP would forward the 802.11 wireless frames directly between clients. But between the company and guest SSIDs which are linked to different bridges and IP subnets, regular routing happens, so the 802.11 frame received from one client arrives to the AP interface, gets converted into an 802.1 frame and is further forwarded to the bridge interface, where the IP packet is extracted from it and routed out the other bridge interface which again encapsulates it into an 802.1 frame and gives it to the other AP interface for wireless (802.11) transmission to the other client.

TBH I really don't care much about WiFi clients, there are only phones there, and may they do what they want.

hm... a malware running on a phone can spread as good as a malware running on a PC. So by blocking only the client to client forwarding at SSID level but not blocking routing between the two wireless networks you've made it impossible for the rogue guest phone to infect other guest phones but not to infect the company phones (or vice versa for a rogue company phone).

mrmut · Sat Jun 08, 2019 3:02 pm

Wow, what an in-depth knowledge. Thanks for taking the time to help.

Will also block talk between WiFi networks in firewall, thanks for a tip. It is actually logical what happens, but I will have to admit that I never thought about it. My primary concern was to protect LAN, however phones are not trivial matter.

I pondered the idea to actually filter out LAN->internet everything except specifically needed egress ports, however the conclusion in the end was that would turn into an administrative nightmare, plus crapware can come in/out over any port / service.

I actually started building stuff on MikroTik relatively recently, learning on the go. I am completing several projects just now, and after that the idea is to dig deeper into stuff RouterOS can do, and add to the existing systems on the go. My presumption is that for starters the relatively default stuff will suffice, especially given that each end-point is additionally protected. I seriously consider implementing MOAB: https://itexpertoncall.com/additional_info/moabpre.html

How to blocking bridge traffic on L2?

How to blocking bridge traffic on L2?

Re: How to blocking bridge traffic on L2?

Re: How to blocking bridge traffic on L2?

Re: How to blocking bridge traffic on L2?

Re: How to blocking bridge traffic on L2?

Re: How to blocking bridge traffic on L2?

Re: How to blocking bridge traffic on L2?

Re: How to blocking bridge traffic on L2?

Re: How to blocking bridge traffic on L2?

Who is online