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?
@uberseehandel
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...
@jdsilvawrote:
. . . 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!
@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. 🙂
@jdsilvawrote:. . . 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.
@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.
@uberseehandel
@3ffdotwrote:@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.
@uberseehandel
@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.
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.
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.
@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.
