Community discussions

MikroTik App
 
gklpnd
just joined
Topic Author
Posts: 6
Joined: Tue Mar 26, 2013 12:44 pm

bridge filter CRS326

Wed Jun 24, 2020 2:40 pm

Hi

Device: CRS326-24G-2S+
Routerboard version: 6.46.4 and 6.47

I created rule in /interface bridge filter:
[host] > /interface bridge filter print
Flags: X - disabled, I - invalid, D - dynamic
0 chain=output action=accept out-interface-list=ether dst-mac-address=01:80:C2:00:00:00/FF:FF:FF:FF:FF:FF log=yes log-prefix="TEST:"
Logs:
[host] > /log print where message~"TEST:"
14:22:41 firewall,info TEST: output: in:(unknown 0) out:sfp-sfpplus2, src-mac b8:69:f4:5d:c9:e8, dst-mac 00:0e:0c:9f:f2:f4, eth-proto 0800, UDP, 10.200.0.12:514->10.200
.0.254:514, len 225
14:22:41 firewall,info TEST: output: in:(unknown 0) out:sfp-sfpplus2, src-mac b8:69:f4:5d:c9:e8, dst-mac 00:0e:0c:9f:f2:f4, eth-proto 0800, UDP, 10.200.0.12:514->10.200
.0.254:514, len 225
14:22:41 firewall,info TEST: output: in:(unknown 0) out:sfp-sfpplus2, src-mac b8:69:f4:5d:c9:e8, dst-mac 00:0e:0c:9f:f2:f4, eth-proto 0800, UDP, 10.200.0.12:514->10.200
.0.254:514, len 225
Why this rule matched all packets?

Another rule (try to block vrrp by protocol ip 112):
[host] > /interface bridge filter print
Flags: X - disabled, I - invalid, D - dynamic
0 X chain=output action=accept out-interface-list=ether dst-mac-address=01:80:C2:00:00:00/FF:FF:FF:FF:FF:FF mac-protocol=ip log=yes log-prefix="TEST"
1 X chain=forward action=drop out-interface-list=ether dst-mac-address=01:80:C2:00:00:00/FF:FF:FF:FF:FF:FF log=no log-prefix=""
2 X chain=output action=accept out-interface-list=ether dst-mac-address=01:00:0C:CC:CC:CD/FF:FF:FF:FF:FF:FF log=yes log-prefix="TEST:"
3 X chain=forward action=drop out-interface-list=ether dst-mac-address=01:00:0C:CC:CC:CD/FF:FF:FF:FF:FF:FF log=no log-prefix=""
4 X chain=output action=accept mac-protocol=ip dst-address=224.0.0.0/24 log=yes log-prefix="TEST2"
5 X chain=output action=accept mac-protocol=ip src-address=224.0.0.0/24 log=yes log-prefix="TEST2"
6 X chain=output action=accept mac-protocol=ip log=yes log-prefix="TEST2"
7 chain=output action=drop mac-protocol=ip ip-protocol=vrrp log=yes log-prefix="TEST2"
Logs:
[host] > /log print where message~"TEST2"

[host] >
I checked with wireshark all vrrp packets have transmited.

Bridge settings:
[host] > /interface bridge settings print
use-ip-firewall: no
use-ip-firewall-for-vlan: no
use-ip-firewall-for-pppoe: no
allow-fast-path: yes
bridge-fast-path-active: no
bridge-fast-path-packets: 0
bridge-fast-path-bytes: 0
bridge-fast-forward-packets: 0
bridge-fast-forward-bytes: 0

[host] > /interface bridge print detail
Flags: X - disabled, R - running
0 R ;;; defconf
name="bridge" mtu=auto actual-mtu=1500 l2mtu=9214 arp=enabled arp-timeout=auto mac-address=B8:69:F4:5D:C9:E8 protocol-mode=none fast-forward=yes
igmp-snooping=no auto-mac=no admin-mac=B8:69:F4:5D:C9:E8 ageing-time=5m vlan-filtering=yes ether-type=0x8100 pvid=1 frame-types=admit-all ingress-filtering=no
dhcp-snooping=no
Is "/interface bridge filter" working or i missed something?

Thanks!
 
User avatar
mutluit
Forum Veteran
Forum Veteran
Posts: 714
Joined: Wed Mar 25, 2020 4:04 am

Re: bridge filter CRS326

Wed Jun 24, 2020 7:31 pm

FYI: the traffic of ports that have Hardware Offloading enabled, does not pass thru the normal firewall locations ("CPU firewall"), but is handled within the "switch chip" using ACL rules. Ie. you should use ACL rules. There is also a rule which allows to "redirect-to-cpu" : then the packet will traverse the normal firewall locations. ACL is stateless and fast, normal firewall is stateful and slow. See https://wiki.mikrotik.com/wiki/Manual:I ... Offloading and https://wiki.mikrotik.com/wiki/Manual:C ... _.28ACL.29

I think setting use-ip-firewall=yes will solve the problem as well, but then performance will be much slower as now all packets traverse the normal CPU firewall locations.
 
gklpnd
just joined
Topic Author
Posts: 6
Joined: Tue Mar 26, 2013 12:44 pm

Re: bridge filter CRS326

Wed Jun 24, 2020 9:18 pm

FYI: the traffic of ports that have Hardware Offloading enabled, does not pass thru the normal firewall locations ("CPU firewall"), but is handled within the "switch chip" using ACL rules. Ie. you should use ACL rules. There is also a rule which allows to "redirect-to-cpu" : then the packet will traverse the normal firewall locations. ACL is stateless and fast, normal firewall is stateful and slow. See https://wiki.mikrotik.com/wiki/Manual:I ... Offloading and https://wiki.mikrotik.com/wiki/Manual:C ... _.28ACL.29

I think setting use-ip-firewall=yes will solve the problem as well, but then performance will be much slower as now all packets traverse the normal CPU firewall locations.
As i correctly understand "/interface ethernet swith rule" - for input packets, and "/interface bridge filter" - for output and forward

I tried to enable in bridge use-ip-firewall=yes, but result is unhappy (vrrp packets in output chain (/ip firewall filter) not matching and not dropping, in section "/interface bridge filter" - packets not filtering too)

Also i created some rule (number 4), but result - same:
[host] > interface ethernet switch rule print
Flags: X - disabled, I - invalid, D - dynamic
0 switch=switch1 ports=sfp-sfpplus2,sfp-sfpplus1,ether24,ether23,ether22,
ether21,ether20,ether19,ether18,ether17,ether16,ether15,ether14
dst-mac-address=01:80:C2:00:00:00/FF:FF:FF:FF:FF:FF copy-to-cpu=no
redirect-to-cpu=no mirror=no new-dst-ports=""

1 switch=switch1 ports=ether13,ether12,ether11,ether10,ether9,ether8,ether7,
ether6,ether5,ether4,ether3,ether2,ether1
dst-mac-address=01:00:0C:CC:CC:CD/FF:FF:FF:FF:FF:FF copy-to-cpu=no
redirect-to-cpu=no mirror=no new-dst-ports=""

2 switch=switch1 ports=sfp-sfpplus2,sfp-sfpplus1,ether24,ether23,ether22,
ether21,ether20,ether19,ether18,ether17,ether16,ether15,ether14
dst-mac-address=01:00:0C:CC:CC:CD/FF:FF:FF:FF:FF:FF copy-to-cpu=no
redirect-to-cpu=no mirror=no new-dst-ports=""

3 switch=switch1 ports=ether13,ether12,ether11,ether10,ether9,ether8,ether7,
ether6,ether5,ether4,ether3,ether2,ether1
dst-mac-address=01:80:C2:00:00:00/FF:FF:FF:FF:FF:FF copy-to-cpu=no
redirect-to-cpu=no mirror=no new-dst-ports=""

4 switch=switch1 ports=switch1-cpu mac-protocol=ip protocol=vrrp
copy-to-cpu=yes redirect-to-cpu=yes mirror=no

[host] > interface bridge filter print where disabled=no
Flags: X - disabled, I - invalid, D - dynamic
0 chain=output action=drop out-interface=ether18 mac-protocol=ip ip-protocol=vrrp log=yes
log-prefix="TEST2"
[host] > interface bridge filter print stats where disabled=no
Flags: X - disabled, I - invalid, D - dynamic
# CHAIN ACTION BYTES PACKETS
0 output drop 0 0
 
User avatar
mutluit
Forum Veteran
Forum Veteran
Posts: 714
Joined: Wed Mar 25, 2020 4:04 am

Re: bridge filter CRS326

Wed Jun 24, 2020 10:02 pm

@gklpnd, I have no experience with VRRP. I would suggest to experiment with a simple "normal" TCP traffic to/from a TCP port, for example by using an iperf server and a client. Then you will have gained more experience and can apply it to VRRP etc.

All ACL rules have an implicit "action=accept", except the last rule which should be like this one (ie. is like an action=drop):
add switch=switch1 ports=$myPorts new-dst-ports="" comment="block all other"
See also the first example under https://wiki.mikrotik.com/wiki/Manual:C ... t_Security where the above said is applied.

BUT beware: you can lock yourself out of the device! So, make backup and use the "Safe Mode" button in the GUI (Webfig, Winbox).
 
gklpnd
just joined
Topic Author
Posts: 6
Joined: Tue Mar 26, 2013 12:44 pm

Re: bridge filter CRS326

Thu Jun 25, 2020 11:35 am

@gklpnd, I have no experience with VRRP. I would suggest to experiment with a simple "normal" TCP traffic to/from a TCP port, for example by using an iperf server and a client. Then you will have gained more experience and can apply it to VRRP etc.

All ACL rules have an implicit "action=accept", except the last rule which should be like this one (ie. is like an action=drop):
add switch=switch1 ports=$myPorts new-dst-ports="" comment="block all other"
See also the first example under https://wiki.mikrotik.com/wiki/Manual:C ... t_Security where the above said is applied.

BUT beware: you can lock yourself out of the device! So, make backup and use the "Safe Mode" button in the GUI (Webfig, Winbox).
Yes switch rules with new-dst-ports="" are working (packets successfully dropped), but this is ingress packets.
I'm trying to block output packets.
 
User avatar
mutluit
Forum Veteran
Forum Veteran
Posts: 714
Joined: Wed Mar 25, 2020 4:04 am

Re: bridge filter CRS326

Sat Jun 27, 2020 3:26 am

Yes switch rules with new-dst-ports="" are working (packets successfully dropped), but this is ingress packets.
I'm trying to block output packets.
You can do that via
src-address (IP address/Mask)

Ie. via the mask you can cover all your LAN...
See the ACL table in one of the links I had posted.
 
sindy
Forum Guru
Forum Guru
Posts: 5342
Joined: Mon Dec 04, 2017 9:19 pm

Re: bridge filter CRS326

Sat Jun 27, 2020 10:20 am

As i correctly understand "/interface ethernet swith rule" - for input packets, and "/interface bridge filter" - for output and forward
It's more complex. In both /interface bridge filter and /ip firewall filter, forward handles frames/packets which are being forwarded from an ingress port to an egress port, input handles frames/packets for the router itself (i.e. there is no egress port for them), and output handles frames/packets sent by the router itself (i.e. there is no ingress port for them).
The rules under /interface ethernet switch rule are handled by the switch chip itself as the frame enters the switch chip; it does not matter whether the destination is the router itself or some external device. So frames coming in to the switch via its physical ethernet ports may be either input or forward ones; it seems that frames coming in to the switch via its CPU port can be only output ones, but if you combine forwarding in switch chip with the software bridge, these frames can actually be forward ones too.
Instead of writing novels, post /export hide-sensitive. Use find&replace in your favourite text editor to systematically replace all occurrences of each public IP address potentially identifying you by a distinctive pattern such as my.public.ip.1.

Who is online

Users browsing this forum: deanz, eworm, tdw and 57 guests