Firewall rules best practices.

rabusiak
Getting noticed

Firewall rules best practices.

I'm going to start setting up firewall rules on my Meraki firewalls and I would like to ask more experienced users what the best practices are and how should it be done properly 🙂

I have AutoVPN setup build with 2 hubs - HQ (mx105) & vMX in Azure (ClientVPN there), 5 branch offices aka spokes (5x mx67) + non meraki peer (other company). Should I setup firewall rules between networks of different peers on Security&SDWAN->Firewall or maybe on Security&SDWAN->Site-to-site VPN->Org. wide settings? What are prons&cons of setting them in first vs second place?

Default rule at the bottom of firewall ruleset is allow any/any. I planned to put all my "custom allow" rules above and then create one deny any/any just above the default. I believe that setup will cut my clients from internet, right? How to create allow rule saying, "allow all outgoing traffic to internet"? 😉

I have company wifi which has radius auth - active directory accounts. It is separate network/vlan. I would like to somehow control also which devices can access this network. How can I achieve this? Should I create group policy, assign it to all known devices and have custom firewall set to allow internal and external traffic? If I then create regular rule saying block traffic from this network to any directions those devices with assigned group policy will use "their custom firewall only" and will be allowed? Those devices out of my group policy will be cut off from any network based on general firewall rule, right?

I'm planning to implement bunch of test rules for couple of weeks, for example:
allow any traffic from network A to network B with enabled logging.
I parse the flows to syslog (graylog) and analyze what kind of traffic is flowing between network A&B to decide which should be allowed and base on those observations create granular allow rules, separate for tcp, udp and icmp and deny the rest. I need some help with understanding logs I'm getting that way, I know that generally pattern 0 means allowed, and pattern 1 means blocked/deny. When I see logs which hits my test rules, they look like this:

pattern: allow (dst network-A/24) && (src network-B/24)

What I'm not sure is the meaning of:

pattern: 0 all
pattern: allow all 
pattern: 1 all

How to treat them? "Allow all" means it hits default allow rule? What just "all" means when it is allowed or blocked?



8 Replies 8
alemabrahao
Kind of a big deal
Kind of a big deal

It's a lot of information. First of all, have you consult the Meraki documentation? Take a look on these best practices:

 

 

https://documentation.meraki.com/日本語/Architectures_and_Best_Practices/Cisco_Meraki_Best_Practice_Des...

 

https://documentation.meraki.com/Architectures_and_Best_Practices/Cisco_Meraki_Best_Practice_Design/...

 

For the wireless clients, do you have SM? I thonk It's the best way to controll, also you can apply policies by device type, look this:

 

https://documentation.meraki.com/MR/Group_Policies_and_Block_Lists/Applying_Policies_by_Device_Type

I am not a Cisco Meraki employee. My suggestions are based on documentation of Meraki best practices and day-to-day experience.

Please, if this post was useful, leave your kudos and mark it as solved.
rabusiak
Getting noticed

Yup, I've read the docs but there are no answers to my questions 😉
In HQ I have MXs and MSs, in branch offices only MX's. We do not use MRs as access points unfortunately.

alemabrahao
Kind of a big deal
Kind of a big deal

I think It's a good idea to consult a Maraki partner. It looks like a project 😅, but the documentation hs all informations, you just need to perform some labs to undesrtand how It's work, there is no easy way man. 

I am not a Cisco Meraki employee. My suggestions are based on documentation of Meraki best practices and day-to-day experience.

Please, if this post was useful, leave your kudos and mark it as solved.
Brash
Kind of a big deal
Kind of a big deal

You'll most likely find that people tend to design their networks differenly based on requirements. There's really no hard and fast rule for a lot of what you're asking.

 

That said, a few comments to help get you started:

- Read up and understand where different firewall rules apply. For example MX L3 firewall rules don't apply to traffic transiting a site-to-site VPN. You would need site-to-site VPN firewall rules for this traffic.

- Apply firewall rules as close to the source as possible

- When planning the rules remember, someone has to maintain them. Complex rulesets quickly become overwhelming if they're not very well documented. Sometimes it's easier to be a little more open for the sake of simpler rules and thus fewer mistakes in creating and maintaining them.

- Meraki has many places to put firewall rules (MR, MS, MX, group policy etc.) I suggest try bring consistent for wherever you place the rules. There's nothing worse than trying to troubleshoot a problem through a tonne of rules across multiple locations.

- An "Allow all traffic going to internet" rule is basically "a deny traffic not going to the internet" rule - deny 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16

rabusiak
Getting noticed

Thanks for the tips 🙂


@Brash wrote:

For example MX L3 firewall rules don't apply to traffic transiting a site-to-site VPN. You would need site-to-site VPN firewall rules for this traffic.

So, if I create rule "deny traffic from vlan1 to "any" it will not block the traffic to networks on the other end of auto vpn tunnel? Thats kind of violation of ANY terminology 😉 Need to test that 🙂

 


@Brash wrote:
An "Allow all traffic going to internet" rule is basically "a deny traffic not going to the internet" rule - deny 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16

I used this kind of rule on other firewalls, but it will not work on Meraki in a ruleset I think about to build (because Meraki cannot be set to drop by default?)
1. Deny "guest" to "10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16" - blocking guests to internal stuff but leaving them access to internet
2. Allow something from "lan" to "srv"
3. Allow something from "mgmt" to "srv"
4. Allow anything from "admin" to "any"
5. Deny "any" to "any" - clearing rule.
6. Allow all (default rule)

Nothing will reach last rule and all clients will be cut off from internet, right?

alemabrahao
Kind of a big deal
Kind of a big deal

@rabusiak,

 

 

The best way in tah case is using a Group policy and applaying it on VLAN, like this:

 

alemabrahao_0-1664547336633.pngalemabrahao_1-1664547404012.png

 

It will block all LAN access but you still having internet access.

 

I am not a Cisco Meraki employee. My suggestions are based on documentation of Meraki best practices and day-to-day experience.

Please, if this post was useful, leave your kudos and mark it as solved.
rabusiak
Getting noticed


@rabusiak wrote:

Thanks for the tips 🙂


@Brash wrote:

For example MX L3 firewall rules don't apply to traffic transiting a site-to-site VPN. You would need site-to-site VPN firewall rules for this traffic.

So, if I create rule "deny traffic from vlan1 to "any" it will not block the traffic to networks on the other end of auto vpn tunnel? Thats kind of violation of ANY terminology 😉 Need to test that 🙂

I created standard L3 firewall rule saying block all icmp traffic between 2 hosts behind different MX devices connected with AutoVPN tunnel and traffic was blocked 🙂

GIdenJoe
Kind of a big deal
Kind of a big deal

First it depends if you are routing in the MX or on a switch below it.

Usually if you have general rules that apply to entire networks then just put them in the general firewall outbound ruleset.  If you need your clients to dynamically authorize on the network but they all follow a same kind of ruleset as explained above I would just let your radius server define the VLAN your client is on and not apply a group policy.

However if you have a few special clients that need a complete different firewall ruleset then you can use a group policy for that.

 

However you'll find the custom firewall inside group policies to be a little less flexible with mixing port ranges and commas because group policies must also fit onto a switch or access point which have far less flexible rulesets.

 

Also if you would have a L3 switch below your MX and you also have access points then group policies will be applied on the AP instead.  In that case it might be a good idea to split your network between MX and AP/Switch and track by IP address on the MX network.  So you are always sure where your policy will be applied for both AP and Switch clients.

 

Finally as best practice on your general ruleset.  Start off with some default rules and try to only use them once.  So one rule for HTTP/HTTPS traffic and make sure all your source clients are on that one rule.  You can use policy object groups to make it more concise.

After you've done the usual rules, http/https, dns, ntp, mail in, mail out, apple push, whatsapp and all that jazz, you can start with custom rules then.

 

For interVLAN traffic if you are routing on the MX then just put those before the internetbound rules and group those rules per sourcing VLAN to make it more readable.

Get notified when there are additional replies to this discussion.
Welcome to the Meraki Community!
To start contributing, simply sign in with your Cisco account. If you don't yet have a Cisco account, you can sign up.
Labels