MX250 and Inter-VLAN rules - Entropy Reigns Supreme

ShaunCro
Here to help

MX250 and Inter-VLAN rules - Entropy Reigns Supreme

Hi All,

 

I work for a Uni in SA, we just moved over our old network to a full meraki deployment and..... I'm loving it. The amount of info available in one place and at the click of a mouse button is just awesome.

 

There is, how ever, one thing that I'm not enjoying and that is the layout of the Meraki firewall rules, coming from a fortigate background where I have always done my inter-vlan routing, they don't make sense to me, just a convoluted list of stuff thrown on a web page with no segregation by vlan or interface, be it virtual or physical, and to be honest, I am battling to get the rules in place that I need. I have 24 vlans that I manage.

 

For instance, I'll add a rule right at the top of the list, just to watch the hit counter, and it will stay on 0, and its not because I am expecting something to hit it too quickly, I can leave the page open for hours and never see anything hit port 53 from any of the vlan's even though the rule is specific to our internal dns servers, as a real example I have attempted a few times.

 

We are running 2 x MX250's in HA (Hot\Warm) spare config with auto failover and it just works, haven't had an issue there, but the rules..... I can add stuff in any order and don't see hits, but others I do, to me it's a mess. 

 

Is there something out there that can add some sanity to the entropy? What is everyone using to manage their rules properly and get proper visibility of the rules in place for the different vlans?

 

Thanks

ShaunCro

12 Replies 12
RWelch
Kind of a big deal
Kind of a big deal

You might consider taking a look at the free online training courses on the Meraki Learning Hub:
Implementing Firewall Rules on a Security Appliance

This module will enable you to:

  • Configure and deploy layer 3 firewall rules
  • Configure and deploy layer 7 firewall rules
  • Describe how the Meraki security and SD-WAN appliance processes layer 3 and layer 7 rules
  • Configure and implement firewall policy objects
  • Enable ICMP, SNMP, and local status page access from the WAN

 

You would want and need to be methodical on how you add the list (order of precedence) and not just all thrown on a webpage without regard to the sequencing or order - the rules would need to be applied from a holistic top down sequence which does take planning and a little bit of organization according to your network needs.

Layer 3 and 7 Firewall Processing Order 

Network objects can be utilized and often best if you and your fellow admins come up with a semi-standardized naming convention if you have a complex environment.

Network Objects Configuration Guide 

 

And lastly, if you apply any custom group policies with custom L3/L7 firewall rules the default rules wouldn't apply as you are telling the client to use whatever custom group policies vs the default so that is another factor to take into the equation.  

 

The hit counter only increments for traffic that matches the rule exactly.
If you’re not seeing hits, double-check the source/destination, protocol, and port definitions.
DNS traffic (port 53) may be bypassing the MX if clients use external DNS.

If you found this post helpful, please give it Kudos. If my answer solves your problem please click Accept as Solution so others can benefit from it.
ShaunCro
Here to help

 

"The hit counter only increments for traffic that matches the rule exactly.
If you’re not seeing hits, double-check the source/destination, protocol, and port definitions.
DNS traffic (port 53) may be bypassing the MX if clients use external DNS."

Just on this one @RWelch That i understand, but I control the dhcp, and it doesn't matter if I put the rule on for my IP with the destination being directly to my DNS servers, and place the rule at number 1 and 2 in the list and then spend the rest of the day browsing the internet, not a single hit that have I seen. For both tcp and udp traffic, it boggles my mind a bit. I just don't see a hit on the rule. I've even tried to give myself a static IP with static dns servers and tried from a few different vlans to ensure that I traverse the firewall, so definitely not intra-vlan, and I will get el squatto. Nada. Zip. Zero. Nothing. Not a single hit. But, I agree, people could be setting external DNS's servers, but if a single staff member wanted to work at all in the day (I do question whether this happens at all sometimes), they would need to have my internal AD servers as DNS in order to successfully authenticate to the internal systems, and that traffic would come from the user vlan, and traverse the firewall, so at least a few hits should be seen. Also, we don't allow staff to edit firewall or network configurations via group policy, so if all 355 staff really did go to the lengths needed to by pass all of that and actually know what a dns server is, I would be both impressed and worried. Our oldest professor makes my grandad look like a spring chicken. And he curses at his phone most the day. I'm pretty sure it's a nokia too, so not overly complicated.

ShaunCro
Here to help

Thanks @RWelch I have done the course you recommended above. And believe me, I'm pretty methodical with the way I do things, I have to be, I come from the finance and insurance industry originally, and believe me they can be pretty.... 

It's why I'm battling to say the least, I'm used to a more organised and clinical format, and it doesn't help that the company that deployed the initial equipment for us were also still learning the product. So at this point, I'm doing cleanup, but it's hard since we technically operate 24 hours a day, being a campus. I've put my port on a test VLAN and typically add my rules there to test before roll out. I like to group my rule sets together, so by vlan essentially, but the list of everything together get's to me. Even using the search just to narrow it down to a specific vlan and the rules associated to it, has lead to me deploying a rule in the wrong place and it just doesn't work. So I was hoping there was a way or an app or service that would organise the rules in a easier to use manor. 

RWelch
Kind of a big deal
Kind of a big deal

We all face the same challenge/task when implementing - so you aren't alone.  If the reference aren't of assistance to you, you can always provide feedback to the engineers for a feature that would benefit you and your organization.  Best of luck!

Give your feedback (previously Make a Wish) 

 

Also, the Cisco Networking App Marketplace might offer you a solution that integrates with the Meraki Dashboard.

If you found this post helpful, please give it Kudos. If my answer solves your problem please click Accept as Solution so others can benefit from it.
ShaunCro
Here to help

I was hoping that someone could perhaps recommend an app from the app store that could help in this. I mean, there has to be something better, or is my hope akin to that of a child that is yet to experience life?

PhilipDAth
Kind of a big deal
Kind of a big deal

Meraki is not the best in real-time monitoring in this area.  Try using the live "Firewall Logging" tool instead.

https://documentation.meraki.com/MX/Firewall_and_Traffic_Shaping/Firewall_Logging

 

 

 

ShaunCro
Here to help

Thanks @PhilipDAth I'll do so in future, but the only reason I use the hit counter is to see whether a rule being applied is being hit before the subsequent rules, it helps to ensure I don't block something, so first I will set it to enabled and see how much traffic is hitting it, from there I'll make the call on whether to flip it over to deny. It's typically used as a gauging tool to measure the level of "entropy" you will introduce to your life before enacting said life changing rule. Sometimes, with the meraki firewall interface, I prepare my CV before starting my change. And tell the wife we might have to cut back on the luxury stuff, like food, for a while.

ShaunCro
Here to help

 

So, on the 53 rule for monitoring. Managed to figure that one out. The trick was to be less specific. So source port any, destination port 53, then vlans in the source by their object names, which were configured already, to destination object names, both dc's. And the hits started rolling. 

RWelch, I'm dealing purely with firewall rules, no custom group policies or the like. Pure layer 3 inter-vlan firewall rules. Nothing else, because I work methodically, and you can't add more complex things on top until you have the fundamentals working properly. And with all you said, you never actually answered my question, which was on the last line. I wanted a solution that is cleaner than this mess. And whether it's perfect outlined in perfectly listed order or not, I don't like the way it's laid out, and was asking for another solution, something you completely glossed over. Instead it was just suffer like the rest of us. Which I choose not to do. 

 

So thought well I'm bored, I'll just roll my own. Because accepting mediocre is not something I do personally.

alemabrahao
Kind of a big deal
Kind of a big deal

To be honest, there's no tool that "organizes" the rules.

Unfortunately (or fortunately, depending on your perspective), Meraki's intention is to simplify things.

Can it be improved? Definitely, but I believe this will only happen if everyone who uses MX today joins forces and requests improvements from Cisco.

We must understand that whether Cisco modifies or adds new features will depend on customer requests and the number of customers requesting a new feature.

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.
ShaunCro
Here to help

Thanks Alemabrahao, it's actually the biggest failing point of what is a phenomenal solution. But anyone that has worked with a 'Security Appliance" before would know what I mean when I say, the way it's currently expected to be used leaves too much room for mistakes, especially in larger networks, I get the ease of management, I do, but if there is one thing you don't allow room for mistakes, it's the security that sits in between your vlans, and at your perimeter. I'm the only one that has taken the time to learn the equipment out of a team of 3, I've sat most nights running through courses and reading the docs (Sorry RWelch didn't mean to do that) and I'm the only one that has actual experience managing firewalls, so, what happens when I'm away or unavailable and someone else who doesn't understand the intricacies of the system tries to apply a rule? The format is geared for a single vlan configuration, not for something that actually requires a bit thought. We all know how dangerous a bit of knowledge is, now make it look simpler than it is and you have a security incident on your hands. I mean it's cisco, grab an engineer and ask him what he expects on a management page at minimum. The platform is fantastic, and I honestly am loving it. I just want the most dangerous part to have more context and structure.

alemabrahao
Kind of a big deal
Kind of a big deal

Yes, I understand you perfectly, one of the things that bothers me the most is the fact that you can't define different zones for the rules.

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.
ShaunCro
Here to help

oh yes. Also, as I discovered yesterday, dynamic ports aren't considered or catered for in rules, so even though traffic is destined for a port and the service typically is available on that port, the MX doesn't pick up that the port could be dynamic from the source, and record the traffic or attempt to do anything because you defined a specific port on both sides. I loathe the use of "Any" in any situation other than a deny. It's just poor management practices. 

Get notified when there are additional replies to this discussion.