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.
Solved! Go to 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.
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.
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.
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.
>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 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
I also found out that there is no option to aggr interfaces in the MX (they are working on it with high priority).
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.