MX Limitation

[Hussam-Bay]

Hi Everyone,

We're going to deploy MX Firewalls very soon and I'm checking some stuff. I'm stunned by its limitations:

1- No SSL Decryption (what's the point to have AMP license without the ability to decrypt the traffic and inspect it)

2- No SSL-VPN application or AnyConnect, we have to use windows and it doesn't support split tunneling and we need to add the routes manually

3- No BGP supported

4- No OSPF on MX appliances

My question is what other limitations does MX have which I'm not aware of, can someone list them, for example, Firepower vs Meraki.

[NolanHerring]

Not sure about #1 but I agree with you on #2 its a big pain point everyone has had.

The other thing I can think of is no IPv6 support, another big issue most everyone has complained about.

[NolanHerring]

As for #1, here is an older thread on the SSL Decryption subject, with responses from Meraki employee. Worth a read.

https://community.meraki.com/t5/Security-SD-WAN/Confirmation-on-HTTPS-decryption/td-p/4561

[Hussam-Bay]

Thanks for the URL, do you know any other limitations?

[NolanHerring]

Nothing else specific comes to mind. Other than the hardware throughput and VPN connection limits per model which you can view here:

https://meraki.cisco.com/lib/pdf/meraki_datasheet_mx.pdf

[jdsilva]

Limitations often depend on your point of view, and use case. What you consider a limitation (no SSL-decryption) I consider a blessing (MitM'ing your users is wrong. Use endpoint security).

Every person here will likely have slightly differing lists. 

[Owen · Accepted solution]

Its probably quick to list what they are capable of rather than listing limitations 🙂 The only thing I like them for is templating large numbers of branch site routers & access-points and only if the branch sites have internet connections rather than private VPN / MPLS.

NAT is major limitation. Basic destination NAT (port forwards), static NAT (1:1) only. No way to choose which IP is used for source NAT for traffic not returning for an existing flow. No way to disable NAT on WAN interfaces and the 15.x beta that permits you to disable NAT on a VLAN basis has other issues.

Basic L3 & L4 firewalling works but the interface is horrible. No way to add addresses or address-sets (objects and object groups). The only protocols supported for access-list entries are ICMP, TCP, UDP and "any".

No routing protocols limits their use cases in DC's. Warm spare with VRRP on internal interfaces is the only redundancy method. Avoid installing in active/active DC environments.

Non-Meraki VPN tunnels have problems as there is no way to customise the list of subnets used for the security associations on a tunnel by tunnel basis. Non-meraki tunnels need to be done on a separate device.

QoS is very limited. You'll probably have to do QoS policies on other devices around the firewall if you have complicated policies to replicate.

No visibility into what is happening on the firewall in regards to active flows, flow timeouts etc. Very limited troubleshooting methods for interrogating the firewall itself.

Multicast, IPv6, real client VPN, SSL inspection are missing. MX firewalls are useful for basic SMB and simple branch installs with VPN concentrators in the DC but once you add up all the costs including putting in a real firewall and optionally web-proxies for SSL decrypt the costs start increasing way past the benefits given.

[Hussam-Bay]

Thanks for the clear explanation and all the information. Well said!!!

[dalmiroy2k]

I would add capped max uplink bandwidth. Example: MX64 can only process up to 250 Mb WAN. Cisco ISR 4000 series suffer the same fate, unless you use the Boost Licence which unlock the limitations.

[PhilipDAth]

>3- No BGP supported

This is available in beta.  You have to ask support to turn it on for you.  Although it is in beta, it is very good, and much better than using OSPF below.

https://documentation.meraki.com/MX/Networks_and_Routing/BGP

4- No OSPF on MX appliances

OSPF is limited.  It can only advertise remote AutoVPN subnets, and doesn't listen to routes.

https://documentation.meraki.com/MX/Site-to-site_VPN/Using_OSPF_to_Advertise_Remote_VPN_Subnets

[Pugmiester]

Hi @PhilipDAth,

I'm just butting up against the OSPF restrictions myself. It would be a big help if OSPF was available on an MX in NAT mode to publish the Auto VPN routes to a local LAN gateway for the larger sites we have where the MX will not immediately replace the default router. Looks like a little manual work until we get things organised.

[PhilipDAth]

@Pugmiester  note that you can use OSPF in NAT mode as long as VLANs are disabled.

https://documentation.meraki.com/MX/Site-to-site_VPN/Using_OSPF_to_Advertise_Remote_VPN_Subnets

Personally, I would ask to support to enable BGP.  The BGP implementation is a million times more powerfull.

https://documentation.meraki.com/MX/Networks_and_Routing/BGP

[Pugmiester]

Thanks @PhilipDAth, I spotted the VLAN disabled but unfortunately suppers us right now as all of the larger sites have VLAN's enabled we'd need to router around. I was looking at OSPF because I have a little experience with it and only a passing understanding of BGP.

[SimondeHeer]

I also found out that there is no option to aggr interfaces in the MX (they are working on it with high priority).

[Hussam-Bay]

Also you can't configure IPSec vpn  between two MX if the WAN ports have private IPs. The MX will not negotiate IPSec unless the port has internet connection, the port status will show failure until it gets internet connection. Hence, if you have two sites connected via MPLS then you can't have VPN between them since the WAN ports don't have internet connection.