MX - NO-NAT 15.3 / 15.4

Kind of a big deal

MX - NO-NAT 15.3 / 15.4

It is quite possible that I am reading too much into this capability but - 


if I have another (technically capable) router ahead of the MX, does the NO-NAT option mean that I can avoid double-NATting issues?


This would solve a lot of immediate problems and provide some future-proofing.


  • Upstream router handles the flavour of Source Specific Multicast commonly used by content providers/distributors in Europe and East Asia.
  • Full native IPv6 support and conversion to IPv4
  • Build-in LTE uplink fallback (has SIM card slot)
  • SMS remote reporting and control (inc automated control)
  • monitors state of WAN link (including exchange adjustment of SNR)
  • internal RADIUS server
  • IKEv2

If it works, this pushes the hardware cost up quite significantly for small sites but, it does remove the red flags that currently stop the MX from being deployed at new sites (IPv6, IKEv2, multicast).


Instinctively, I do not like going down the path of adding more hardware to solve problems that should have been addressed by existing hardware (and supposedly will be at some stage), it makes an MX based solution unviable from a financial point of view. There are cheaper options to solve one or two of the issues listed above, but not the full schedule ( and the IKEv2 option is not really convenient).


Views, anybody?

Robin St.Clair | Principal, Caithness Analytics | @uberseehandel
17 Replies 17
Here to help

@Uberseehandel I have this same question in deploying the MX appliance behind an ASA.  I don't want to NAT twice, I just want the MX to be a layer 3 device.  I'm interested in the answer to this.

Kind of a big deal

I have tested this very briefly in my lab and it seems to work well. It does what it advertises and turns the MX into a simple router. I haven't done much comprehensive testing but it does look promising. 


If you do have the MX behind another router then this will avoid a double NAT situation (this is actually the topology I have it my lab that I tested with: Inet---MX---MS---NoNAT MX---MS---Client).


IMO if you have a requirement for the features that you listed @Uberseehandel then I would think you should be looking for a solution that has those features as opposed to stacking multiple hardware platforms that each handle parts of your requirements. But of course, YMMV and sometimes we are forced to do things we don't want to do... 





. . . you should be looking for a solution that has those features as opposed to stacking multiple hardware platforms that each handle parts of your requirements. But of course, YMMV and sometimes we are forced to do things we don't want to do... 

Plenty of us are  asking why such features as native IPv6, IKEv2 are still not available on the MX range. But for me, and many people in Europe and East Asia, the multicast problem is hard to overlook.


But good to know that the NO-NATting works! 

Robin St.Clair | Principal, Caithness Analytics | @uberseehandel

Hah! I ask, on what seems like a daily basis, many of those same questions. My comments weren't meant to tell you what to do, they were simply some philosophical design musings. 🙂


 . . . they were simply some philosophical design musings. 🙂

Thanks, I realised that. I also realise that one of the "Security Gateway" devices I have sitting in the chuck shed can now handle the IGMP proxy required by the multicast stream and also has Open Radius available, and 2 LAN ports, so worth digging it out to see if it can function as an interim solution.

Robin St.Clair | Principal, Caithness Analytics | @uberseehandel

Update - for anybody contemplating IOT / Chromecast / Sonos / Multicast IP TV


The multicast reflector that Sonos-style deployments require does not play well with the IGMP-proxy that the TV streaming needs.

I don't believe we can ignore this stuff.


I bought a light bulb the other day, without really looking, but when I checked my receipt I did a double-take . . . it is "smart" and intended to be controlled in conjunction with lighting devices by some IOT hub. This sort of use is bound to become normal all over the place, homes, offices, warehouses, factories, you name it . . So I hope Meraki is not going to put it on the back-burner; we need to be able to isolate this sort of kit, but still be able to control it from devices with access to the secure VLANs.


I have't begun to test NO-NAT yet, as there are some unresolved issues with respect to how it will operate, and what will do what and to what. to paraphrase.

Robin St.Clair | Principal, Caithness Analytics | @uberseehandel

@jdsilva I have ASA---MX---Layer 3 switch.  The MX doesn't seem to truly be a layer 3 device.  How exactly did you set yours up as a layer 3 device?


@jdsilva I have ASA---MX---Layer 3 switch.  The MX doesn't seem to truly be a layer 3 device.  How exactly did you set yours up as a layer 3 device?

Good question.


At the moment I have removed all the MX and MS power cords. So it is set up as a desk ornament.


The reality is that I am stuck trying to get it to connect to a LAN port on a different device named Kharon . I tried with the MX Internet port configured to use DHCP, plug in anything else and that works, but not the MX. Then I tried with a static address, that also failed, as did forcing an address from Kharon, which can "see" the MX and IP address, but the MX does not connect to the Cloud and does not become operational. The IP being used for the connection does not exist in the MX's network, I tried using a VLAN initially but have given up on that.


The situation now is that I cannot connect to the MX to reconfigure the uplink to use DHCP as all of the LAN ports hand out invalid addresses/gateways. Out of desperation I even resorted to paperclip engineering, but that didn't help.


At the moment it is just another brick in the wall


All suggestions welcome.

Robin St.Clair | Principal, Caithness Analytics | @uberseehandel
Kind of a big deal

@3ffdot I called Meraki and asked them to join the beta. They then set my chosen network to version 15.3 and enabled the feature on that network. 



@jdsilva Right, I get that and I've done that too but how is your MX actually setup?  Do you have layer 3 addresses on it, do you have routes setup on it?  From what I've read and talking to support, the MX doesn't actually work as a layer 3 device unless it is replacing your end point router or firewall.  

Kind of a big deal

Does this help?




And then on the MX I have that is doing NAT I have a static route pointing to the No-NAT MX to get reachability to the subnet behind the No-NAT MX. 


That's it. 

@jdsilva I guess my concern is this MX actually working with Cisco.  You're saying that you don't actually have a layer 3 address on the NO NAT MX?  It looks like you're using the management IP of the MX for routing.  With the IP's that are behind the MX, do you have them tagged on whatever port goes to your LAN and is the IP of the NO NAT MX on the same subnet as the layer 3 switch that it's connected to?  If I put a subinterface on my ASA with the same subnet as the NO NAT MX that should be enough given that the ASA already has a route to the layer 3 switch.  How does the MX know though?  The reason for all my questions is that this is on an active network and I don't want a long outage for a solution that might not even be viable for this type of topology.

Kind of a big deal

No, I have two addresses on my No-NAT MX. You still configure the WAN port the way you always would by either leaving it as DHCP no VLAN tagging, or use the local status page to set up a static IP and VLAN tags. From there the "Addressing & VLANS" page you can set up the LAN side of the device. Add your VLANs, configure your ports, and add any needed static routes. 


The only difference here now is traffic isn't NAT'd. 

@jdsilva I see, ok well I have time this evening so I'm going to take a look at this and set it up. Is your second IP address tied to an interface or is it simply one of the VLAN's you added to the MX? Thanks for your responses.

Kind of a big deal

@3ffdot Nothing changes with regards to IP configuration. So you can configure an IP on the WAN port, but for the LAN you still have to set it on the VLAN and then configure your LAN ports as access or trunk accordingly.


To use non-Meraki terminology, I haven't seen a way to configure a LAN port as a routed port. They can only be switchports that you can assign to a VLAN and route via an SVI.

Comes here often

I need this feature in order to pass traffic to a next hop Fortinet Firewall that is transporting the traffic to Zscaler via a primary and backup GRE. Zscaler needs to see the clients source IP therefore traffic must not be NAT'd

I hope this feature will allow me to pass the traffic to Fortigate and down the GRE to Zscaler.


Meraki integration with Zscaler cloud is a problem requiring additional firewalls that are dual GRE capable. However if the MX supported dual IPSEC with failover that would also solve the problem as long as we could remove the NAT. However so far the MX only supports 1 x IPSEC so I need an additional interface to get the traffic to Zscaler via a tunnel.



Probably someone can point out the differences/advantages when using NO NAT on a WAN-Interface... for example: will statistics, content filtering, etc. may also work with it?

Get notified when there are additional replies to this discussion.
Welcome to the Meraki Community!
To start contributing, simply sign in with your Cisco account. If you don't yet have a Cisco account, you can sign up.