One or more of your Meraki devices are unable to communicate with this new IP range

[Uberseehandel]

I receive the message. What am I supposed to do? I'm not Mystic Meg

[ww]

you need to allow communication from your meraki device to that ip range. there is probably a firewall or acl that is now blocking this

[SoCalRacer]

If nothing has changed on your end, it sounds like your ISP might be blocking the new IPs or ports. Sometimes these things are fixed by the provider relatively soon on their own. Sometimes they are not so quick and need a call to help get it resolved. I would start with your MX or Z device and work on getting that to show connected to the Meraki cloud first.

[Uberseehandel]

@ww 

@SoCalRacer 

I am adding the specified L3 outbound firewall rules.

It seems very long winded.

It would help if we were able to use Firewall Rule Groups, the source IPs don't change and the destinations are largely similar, we could use Source Groups, Destination Groups and Port Groups and classify them into inbound and outbound, setting protocols and descriptions for each rule the Groups are applied to.

So could I achieve the same ends by the use of policies?

As this is, in large part, a Meraki Cloud issue, I can't help feeling this is down to Meraki. This could be more simply solved by sending an email listing the rules they want to active, and asking for permission.

I am also puzzled, why do all the local networks have to be entered? Network devices are all on the Management VLAN.

By design the default 192.168.1.0/24 LAN goes no where, it does not get uplinked. Is Meraki making use of this? Is this an oversight, it would certainly be described as flying in the face of conventional wisdom.

As the MX sits behind another security appliance, and when at home, the Z3C is attached to the MX, this is going to be a very tedious process. Fortunately, Group Policies for Firewall configuration are available on the other security appliance.

As Henry V said, "Once more unto the breach"

[ww]

only the source networks where your management ip(s) are in would be sufficient.

[Uberseehandel]

---

@ww wrote:

only the source networks where your management ip(s) are in would be sufficient.

---

That is what I would think, BUT, if that is so, why are Meraki asking for all local networks to be added?

[PhilipDAth]

A lot of these warnings are false positives.  You get them even if their is nothing wrong.  So chances are you don't have anything to do.

We've had so many of them over the years with customer that have their Internet circuit plugged directly into their MX, so there is nothing blocking the traffic.

Failing that if you know you are restricting access you can check the Help/Firewall rules in the dashboard to verify you have let everything through that is needed.

[MerakiDave]

I would also open a case, recently I've seen some issues with some of the 209.206 addresses, and Meraki Support can see the individual firewall tests being made from each piece of equipment, and they may find that some are succeeding and some are not, so it's enough to keep all of the equipment up and online in Dashboard but also enough to generate warning banners.  I saw this recently in my home lab network.  It was nothing to worry about actually, but worth reporting to Support to assist with tracking and resolving the issue, which I believe is a back-end issue.

[Uberseehandel]

@MerakiDave 

@PhilipDAth 

I will open a case.

After some poking around, it appears that the VPN Status page, on both the MX and the Z3C, variably shows the VPN Registry as Connected, Partially Connected, or Not Connected (to the X3Z), while the devices remain wired. When the Z3C is switched over to its LTE modem (aka yank the Ethernet cable), the connection remains in place but the Status pages on the two devices are not uniformly upgraded.

It appears that there is a possibility that the inconsistent reporting of VPN Status across the two devices may be the cause of a false positive being triggered.