MX not stateful?

[CptnCrnch]

Gentlemen,

I‘m relatively new to the Meraki platform though being used to Cisco equipment for ages. Currently I‘m struggling to grasp the MX concept of applying firewall rules, perhaps you‘ll be able to help me out with it:

• My shiny new MX has VLANs enabled to separate some networks, e.g. Servers from clients from DMZ etc.
• I configured a special Group Policy attached to the DMZ VLAN to allow access to some internal systems but blocking everything RFC1918-related.
• Trying to access the DMZ from the client network (no Group Policy or other firewall rules active), I‘m able to see the packets going to the DMZ system but the returning packets are blocked be the MX.
• Implementing a rule within the Group Policy to allow traffic to the client, everything is working as expected.

From my point of view, this is clearly not how a stateful firewall would work. Perhaps I don‘t get the MX concept here but I guess I‘m not the only one who‘s been running into this issue.

After all, my two questions are:

1) Is the MX acting as a stateful firewall or a simple packet filter?

2) What‘s „best practice“ to implement firewall rules on the MX? Global ruleset only? What exactly are Group Policies useful for then?

[Uberseehandel]

You may find Creating a DMZ with the MX Security Appliance helpful.

[CptnCrnch]

Thanks a lot Sir. The process of creating a DMZ or seperate network is rather clear to me.

My question is: why are packets being blocked by the Group Policy rules bound to the egress-VLAN even if the connection is already allowed the ingress interface?

[Uberseehandel]

An explanation from the documentation:

Based on the rules shown below, traffic originating from any host on the 10.0.0.0/8 network that is destined for web server 192.168.1.254 on TCP port 80 is allowed. When the local host communicates with a service on a remote host, it normally picks an ephemeral source port and sends traffic to the port used by the service on the remote host. This is why the source port in this rule is set to "Any." Because there is an implicit allow rule processed last and we want to perform a "Deny" action on all other outbound traffic from hosts on the 10.0.0.0/8 network and the web server, a deny all rule is required. This rule needs to be evaluated right after rule 1. Because the firewall is stateful, replies from the web server to hosts on the 10.0.0.0/8 network are allowed the bypass the deny rule due to the connection is already being established. The deny will rule which is processed second will match all other traffic besides traffic to the web server.

Note: Cisco Meraki firewalls implement an inherent Allow All rule which can't be modified and is the last rule processed. Firewall rules are processed from the top down.

[CptnCrnch]

I‘m hearing you loud and clear sir, that‘s what I‘d expect from every stateful device.

Seems I didn‘t make it clear enough: you‘re referring to the „global“ ruleset only!

Regarding your example: if you‘d now add a Group Policy for the VLAN the device 192.168.1.254 resides on that denies traffic to 10.0.0.0/8, communication will fail although you‘re allowing it from the global ruleset.

That‘s the part (special to the Meraki world) I‘m struggling with. Everything else is completely basic stuff...

[Nash]

I think I may have an answer. In your group policy, are you overriding your global firewall rules? If so, you'll need to recreate your global rules on the group policy.

When you override the firewall rules on a group policy vs the general firewall, I believe the group policy rules become the only rules that affect devices affected by that group policy.

[CptnCrnch]

@Nash: exactly, thank you!

In a nutshell, the setup looks like this:

1) Clients from 192.168.10.0/24 will access servers within the DMZ (192.168.100.0/24)

2) Global ruleset looks like this: allow TCP 192.168.10.0/24 any to 192.168.100.0/24 22,80,443

3) Group Policy bound to the DMZ VLAN permits everything except RFC1918 networks

Accessing the DMZ servers, I see everything going through to the server. The MX will block the returning packets from the server to the client. That‘s what I would expect a stateful firewall not to do. Only if I add allow rules back from server to client in the Group Policy (where of course no destination port can be configured because of the random client source port) I‘m able to make communication happening.

What‘s the use of Group Policies then when you have to reflect access in both places? Especially if you can‘t clearly define the rule „backwards“?

Guess I‘m just using the MX platform „wrongly“ or am expecting it to do more than it‘s able to deliver. Just would like to understand if my approach is simply too stupid or if I‘m getting things completely wrong. From what I can see, flows are not being handled in a stateful manner though.

Perhaps I made my point clear enough now, really hope to be enlightened. 🙂

[Adam2104 · Accepted solution]

Group policy rules are not stateful. Only the firewall configuration page (Security & SD Wan --> Configured --> Firewall) is stateful rules. Group policy rules are basically ACL entries with no state, if you're used to configuring Cisco routers. You'll need to manually allow return traffic if you're planning to use group policy rules.

Note, any rules you apply via group policy will bypass any rules you've got specified in the firewall configuration page. So, if you're using group policy to control internal vlan to vlan traffic, but also want the firewall configuration to apply to vlan to wan traffic you're out of luck. It's a disappointing limitation which has dramatically reduced the usefulness of group policy for me.

[CptnCrnch]

Thank you so much @Adam2104! Looks like we ran into the same trouble. That explains the things I see.

[CML_Todd]

Thanks for the explanation!  I've run into the same issues and this explains a lot.

[CML_Todd]

Do you know if Group Policy rules will also override site-to-site vpn firewall rules?