Meraki Community

Mloraditch

Important notice

USB modems with MX/Z series devices running firmware MX 18 or newer will be limited to best effort support and will not be receiving any future firmware fixes or improvements.

Bug fixes

Corrected an issue that resulted in Non-Meraki VPN tunnels persisting on the backup, non-primary uplink after failing back to the primary uplink when the WAN interface used IPv6.
Fixed an issue that resulted in the VPN status being reported incorrectly for Non-Meraki VPN peers connected via FQDN.
Resolved an issue that could cause MX appliances upgrading to MX 18.2 from very old, unsupported firmware versions to hang during the upgrade process.
Corrected a rare issue that could cause upgrades from MX 18.1 to MX 18.2 versions to fail to complete successfully.
Fixed an MX 18.2 regression that resulted in the link light LED for WAN2 on MX75 appliances failing to light up if WAN2 is the only wired interface in use.
Resolved a rare issue that could result in data failing to pass over the cellular interface of Z3C, MX67C, and MX68CW appliances, even when the modem was reported as connected.
Corrected an issue that could result in MX appliances encountering an unexpected reboot when ThreatGrid was enabled.
Fixed an issue that caused the Non-Meraki VPN service to fail to properly establish IKEv2 tunnels when the MX appliance was acting as the IKEv2 responder and many allowed subnets were configured.
Resolved several cases that could result in an unexpected device reboot.

Legacy products notice

When configured for this version, Z1 devices will run MX 14.56.
When configured for this version, MX400 and MX600 devices will run MX 16.16.9.
When configured for this version, MX64(W), MX65(W), MX84, MX100, and vMX100 devices will run MX 18.107.10.

Known issues status

This list is being reviewed and updated.

Known issues

In rare cases, MX67C, MX68CW, and Z3C appliances may fail to enter into a "Ready" state despite being able to register to a cellular network and obtain an IP address for the modem.
Due to an issue with no known method of reproduction, the IDS and IPS process may unexpectedly restart.
MX AutoVPN tunnels fail to generate new connections when the AutoVPN flow has been blocked or filtered unidirectionally by an upstream or intermediary device. This prevents appliances from automatically working around this partially connected state.
MX appliances may experience unstable eBGP connections when 1) the MX appliance is configured in Routed mode and 2) the MX learns a large number of routes from its eBGP neighbor. This may result in eBGP-learned routes being inaccessible.
Trusted traffic exclusions will not function on Z4(C) appliances if AMP is configured.
Due to an MX 18.211 regression, MX75, MX85, MX95, MX105, MX250, and MX450 appliances when configured as Wireless Concentrator for SSID Tunneling and Layer 3 Roaming, will fail to forward return Radius Authentication traffic causing clients to fail to connect to the SSIDs.

cmr

The known issues list doesn't look very healthy to me, especially the one regarding SSID concentrator limitations!

BHC_RESORTS

@cmr Yeah we won't be able to upgrade to 18.211.2 with that bug in it. Which is annoying as our firmware is now showing a warning for July 6th. And i have no desire to go on the untested 19 train.

BHC Resorts IT Department

Nightstick

i don't want to be the first guinea pig to try this "stable".

FRover

Is this ever going to be fixed??

"In rare cases, MX67C, MX68CW, and Z3C appliances may fail to enter into a "Ready" state despite being able to register to a cellular network and obtain an IP address for the modem."

harmankardon

I am in the same boat. It's incredibly frustrating that such a key feature has been broken for so many firmware versions.

FRover

Being stuck on 1616.9 and behind on security updates is very frustrating because there is no guarantee that our 4G won't function on dozens of devices in the field.

SPieroni

I have several MX84's which are now Legacy devices. Meraki has auto scheduled these devices to be upgraded. Since these are Legacy devices and the release notes state they will remain at 18.107.10 what changes can I expect if any?

Lauzon_C

Just security patches. No new features.

SPieroni

Thank you!

MSakr

Hi

I am not able to upgrade from 18.211 , my options are greyed out

CyberDingo

We are having an issue, and I wanted to see if anyone else if experiencing a similar issue: not sure if it is related.

We updated all our SD-WANs to 18.211.2 recently. We have an issue with users experiencing slow connection speeds to load webpages. After testing with packet captures, we are seeing a lot of "TCP Retransmission" "TCP Dup ACK" "TCP Out-of-order" that I am assuming is causing the slow speeds.

I will test rolling back the firmware this evening and test the packet capture again to see if it makes any difference.

CyberDingo

Discovered this was because of an error on and upstream ISP router. Please, disregard these comments.

zeestrat-nina

We are running into an issue that seemed to show up on firmware 18.211.2.
L3 firewall outbound allow rules with FQDN in destination seems to now only hit sometimes and mostly skip the allow rule.
The new Firewall Log confirms this showing it is hitting the allow only every few requests.
Does not matter if FQDN has single or multiple A records.

Anyone else seeing this as well?

StefanK

We made an update from version 18.107.2 to 18.211.2 and since then the phase 1 handshake failed after the 5th packet. For additional reference there is a FortiADC Loadbalancer in front of the Meraki. We already performed a lot of different tests (different SNATs, DNAT), but what we see in Wireshark is, the first 4 packets are always correctly handled between the LB and the Meraki in a single UDP-stream. Then the 5th packet is send from the LB to the Meraki in a new UDP-stream and the Meraki is answering with an ICMP TTL exceeded packet, causing the IPsec VPN to fail. We also noticed, that when there are no active sessions on the Meraki, the first user, who is trying to establish a VPN tunnel is successful. Any additional attempts are resulting in the ICMP TTL exceeded error.

Is this a bug in this version or does it interfear with any non-optimal setting on the LB? The LB is simply configured in Layer4 mode with UDP profile and doing a SNAT. With the old software version everything runs fine without any changes on any other component. Any ideas how to further troubleshot this?