Equivalents to Sonicwall address and service objects/groups on Meraki MX?

[RJordan-CCS]

Still working on our conversion from a Sonicwall to an MX84.

Am I right understanding that the only way to apply a rule to more than one IP address or CIDR subnet is to use either a comma separated list of IPs or CIDR subnets?  And the only way to define services a rule applies to is a comma-separated list of destination ports?  Layer 3 here, not application.

We have some fairly complex rule sets that, for example, allow devices in a LAN IP range of .10 - .20 to have Telnet, SSH, FTP, HTTP, HTTPS, and two custom ports outbound access via a VPN tunnel to a small group of disjoint IPs at the remote end.  And some with the reverse access defined. 

On the Sonicwall you define the custom ports as nicely named service objects, create a single named service group that contains the two custom and the five built-in service objects, and use that named object in the rule.  You create an address object that is the range x.x.x.10 - x.x.x.20 LAN and an address group that is made up of the created address objects for the disjoint IPs on the remote side (VPN), and use those in the rule.  All neat and tidy, and manageable by updating the objects or groups when needed, don't have to touch the rule.

Unless I'm missing something, on the Meraki you have to put the comma separated list of 11 addresses on the source side, and the comma separated list of IP addresses, and the comma separated list of ports on the remote side of the rule, or else create individual rules per service or per source/destination, which can get out of hand very quickly.

Is this interpretation correct?  Is there a way to do something like named objects or groups for use in rules on the MX84?

[JohnM]

None of that is in the Meraki platform.

[PhilipDAth]

Your interpretation is correct.

[RJordan-CCS]

Ouch. I guess the cloud GUI and its simplification has its tradeoffs in granular configuration and control. The lists of rules are going to be 'epic' unless we simplify things. I'm still wrapping my head around the inability to have rule based control of inbound traffic from non Meraki site to site peers (all of our peers currently are non-Meraki).

Thank you both for responding.

[JohnM]

That, plus lack of access to debug logs, are the two main shortcomings of the Meraki MX line in my opinion. As long as you know what you're getting, they're fine, but certainly not perfect.

Oh, and the third thing -- reliance on junky native IPSEC VPN client. Even though customers have begged for Anyconnect since the Cisco acquisition years ago. 

[PhilipDAth]

@RJordan-CCS I don't think it is a great fix, but you can also use DNS to create IP based access groups.

For example, create an DNS entry called object-a.internal, and give it 10 IP addresses.  Then reference this FQDN in the layer 3 firewall rules.  I know - pretty rough, but it might be easier for you if you have a lot of these.

You could even create an internal domain, firewall.nternal, just to store all these "objects" in.

[PPP]

I'm wondering if you might know the sizing or where is sizing document of how many lines (ACEs) each MX can effectively hold?

Also, I guess delivery of such potentially long ruleset could be more efficiently done using API, then clicky-clicky GUI, right? (if we are talking about dozens of lines/ACEs)

[PhilipDAth]

Someone has already written a command line tool for managing Meraki firewall rules.

https://github.com/meraki/automation-scripts/blob/master/mxfirewallcontrol_manual.pdf

[PPP]

This looks so promising! 🙂
Cheers PhilipDAth
I will give it a go next weekend.

Too bad MX Sizing pdf doesn't provide info on the at least lab/non-real world number or ACEs that could be installed per model.

[bobbya-ny]

Although this thread is from 2018 I felt compelled to add my experience with the MX in regards to other NGFW products. In this case the Sonicwall of which I have installed many over the years.

The Meraki even in 2020 should not be considered a replacement for any firewall where you have many ingress/egress policies. Inclusive of address/service objects/object groups/Range Objects, application or AVC policies,ETC. In addition the MX doesn't segregate traffic like a traditional firewall into zones, ETC. Making it confusing and combersumb to overcome that when designing it into your Edge. Several other shortcomings that hey say are in the pipe line:

No Link Agg support, no support for OSPF or even Cisco's EIGRP.  When implementing Geo filtering no way to see blocked events easily if at all.No support for dual peers with third party firewalls and because its a common org dashboard with say several MX's within different site networks you must add tags at the Org level then choose those tags to filter sites from hitting the third party VPN. No concept of a true L3 isolated interface you have to associated a L2 vlan id. Well in one of my first implementations I looped the network thinking I can have a P2P (MX connected to small switch to connect carrier and 2 MX's) L3 between two sites MX's HQ in HA pair didn't like it.

The Meraki MX does well in a topology where multiple smaller remote sites have MX units and the Head end a larger MX to act as a VPN concentrator. Their auto VPN feature works well here. Then I would backhaul all remote sites thru a true Edge NGFW.

Yes they intro BGP support (still Beta) but it is really only meant for Dynamic routing over VPN.  

[PhilipDAth]

I've now created a script based system that lets you migrate a firewall rule base to Meraki that uses objects, object groups and service groups.

https://community.meraki.com/t5/Dashboard-Administration/Meraki-Object-Groups-You-can-have-them-now/... 

[PPP]

I shall test it sometime later this month 🙂 

[fatek]

So what is the solution to this problem?

I have a VOIP server hosted in the cloud & IP phones behind an MX84.

I would like to allow ports 5060 tcp & udp and 16000 - 32000 udp access from the VOIP server (WAN side) to the phone subnet on the LAN side.

Is there a clean way of doing this?

Doing this in a SonicWall or Ubiquiti is trivial! Why not in the MX?