Hello, we are trying the Mikrotik router boards instead of purchasing more Juniper appliances.
Can we create Zones as in Juniper?
Can we control both the LAN and WAN connectivity within the router board?
Thank you.
No, there is no concept of zones.
Yes, you can control any interface via the firewall.
To expand on fewi’s comment, you could use custom chains in the firewal to emulate “zones”. I believe this is what Juniper and Vyatta do behind the scenes.
/ip firewall filter {
add chain=forward in-interface="ether1" action=jump jump-target="Zone1"
add chain=forward in-interface="ether2" action=jump jump-target="Zone1"
add chain=forward in-interface="ether3" action=jump jump-target="Zone2"
add chain=forward in-interface="ether4" action=jump jump-target="Zone2"
add chain="Zone1" <...>
add chain="Zone2" <...>
}
This should get you started implementing a zone-like functionality.
While that works for some rules you’d apply to zones, there’s no really easy way to emulate the way zone based firewalls address traffic between zones. You can’t specify multiple out-interfaces OR’d together, for example, so there’s no simple way to write “eth0 and eth1 are in zone1, eth2 and eth3 are in zone2, apply this policy to traffic flowing from zone1 to zone2”. Also be aware that the default action is to pass traffic, so you always want a default drop at the bottom of the chain.
To do a zone policy - I’m not particularly familiar with ScreenOS and Vyatta, sorry - like Cisco does, where you assign interfaces to zones, and then create a unidirectional zone-pair with a security policy attached to it, maybe something like the below would work:
/ip firewall filter
# be stateful (equivalent to inspection) and allow return traffic for established connections
add chain=forward connection-type=established action=accept
add chain=forward connection-type=related action=accept
# eth0 and eth1 are zone1, eth2 and eth3 are zone2
# policy for traffic flow between zone1 and zone2
# creates two new chains, zone1-to-zone2 and zone2-to-zone1
add chain=forward in-interface=eth0 out-interface=eth2 action=jump jump-target=zone1-to-zone2
add chain=forward in-interface=eth0 out-interface=eth3 action=jump jump-target=zone1-to-zone2
add chain=forward in-interface=eth1 out-interface=eth2 action=jump jump-target=zone1-to-zone2
add chain=forward in-interface=eth1 out-interface=eth3 action=jump jump-target=zone1-to-zone2
add chain=forward in-interface=eth2 out-interface=eth0 action=jump jump-target=zone2-to-zone1
add chain=forward in-interface=eth2 out-interface=eth1 action=jump jump-target=zone2-to-zone1
add chain=forward in-interface=eth3 out-interface=eth0 action=jump jump-target=zone2-to-zone1
add chain=forward in-interface=eth3 out-interface=eth1 action=jump jump-target=zone2-to-zone1
add chain=forward action=drop
# allow icmp between zone1 and zone2
add chain=zone1-to-zone2 protocol=icmp action=accept
# allow tcp/80 from zone2 to zone1
add chain=zone2-to-zone1 protocol=tcp dst-port=80 action=accept
As long as you’re careful about packetflow and where NAT is applied and reversed it may be easier to use address-lists instead as they can easily contain the subnets behind multiple interfaces. Let’s say eth0 has 10.1.0.0/24, eth1 has 10.1.1.0/24, eth2 has 10.1.2.0/24 and eth3 has 10.1.3.0/24 and we have the same zone policies:
# create address-lists
/ip firewall address-list
add list=zone1 address=10.1.0.0/24
add list=zone1 address=10.1.1.0/24
add list=zone2 address=10.1.2.0/24
add list=zone2 address=10.1.3.0/24
/ip firewall filter
# be stateful (equivalent to inspection) and allow return traffic for established connections
add chain=forward connection-type=established action=accept
add chain=forward connection-type=related action=accept
add chain=forward src-address-list=zone1 dst-address-list=zone2 protocol=icmp action=accept
add chain=forward rsc-address-list=zone2 dst-addrses-list=zone1 protocol=tcp dst-port=80 action=accept
But that is kind of moving away from a proper zone model based on interfaces (you’d need rules to prevent spoofing, for example), and NAT can make it a little difficult to troubleshoot.
I agree. The RouterOS firewall model is different then other routing system firewall models.
I do, however think RouterOS has a more feature-rich, and flexible rule-set to choose from (limited experience though with other systems).