Hi
At the moment my MX is connected to the ISP using PPPoE/PPPoA in bridging mode. It works fine, apart from where it doesn't work.
To address the most pressing issue - inability of MX to properly handle the flavour of multicast I have to use, I am introducing another security device ahead of the MX.
So, I have to change the MX WAN port configuration not to go to a modem but to one of the LAN ports on the additional Security Gateway.
- How do I configure the MX WAN port?
- Do I need to do anything to cope with potential double-NAT issues?
- Presently, all devices are on specific VLANs, with a separate management VLAN.
- What IP do I give the WAN port?
Or
- do I uplink to the new gateway using a LAN port?
presently
>> ISP >> modem >> MX64 >> MS220-8P >> devices
imminently
>> ISP >> modem >> new Gateway >> MX64 >> MS220-8P >> devices
I have upgraded to the latest beta firmware for the MX, so that I can use the NO-NATting option. But NO-NATting has to be turned on by support, I wish to avoid using this option until I have the proposed configuration hardware in place, then, hopefully, all I will need to do is change the NAT configuration NATting will only occur once at the new Gateway device.
I fear that if I have NO-NATting enabled ahead of having both gateway/security devices functioning in series, I will lose internet connectivity.
I would be hugely grateful for some guidance as to the best way of achieving this.
@uberseehandel
@PhilipDAthwrote:I would try and uplink via the WAN port. I would probably just use DHCP on the WAN port, unless you have things being NATed in from the outside world.
Some consumer CPE devices don't allow you to add a route for a remote subnet and to NAT those subnets. If that was the case you would be forced to stick with the MX NATing the traffic, otherwise you would use NO-NAT.
Unless you are using VoIP, you probably wont notice any issues with double NAT (it just feels wrong as an engineer though ...).
I would just give the WAN port a brand new subnet. You should not need to change any of your other VLANs.
Thanks for that.
What comes in from the outside world does what it can to be obliging, and largely goes straight to the nebulosphere rather than via this site, which is only on a "by arrangement" basis. VoIP is, however, very much at the heart of what happens.
@uberseehandel
I've spent most of the weekend stuffing around with the new kit, and upgrading the firmware, SSH'ing in to the devices.
I have roughed out a VLAN scheme that effectively is common across the Brand X and the Meraki networks. My uninformed intention is to move anything "dodgy" to the front end system, so all the AV kit and the playout stuff go up to the front end and is only linked by HDMI to the secure network devices fronted by the MX. All the Chromecast stuff is moving up there as well. Brand X has specifically built into their gateway the ability to allow appropriate access between secure and insecure zones so that Chromecast may function seamlessly when invoked from a secure mobile device.
On Friday morning I inadvertently bought a light bulb that is network aware. That is also destined for purdah. But it does very clearly illustrate that Meraki has to release a strategy to deal with the impact of IoT/Smart Home/Office devices.
@uberseehandel
