Due to underlying changes present in MX 15, MX appliances will now strictly validate the remote ID parameter during VPN tunnel formation. If you notice issues with non-Meraki VPN tunnel connectivity after upgrading to MX 15 for the first time, please ensure the remote ID configured in the site-to-site VPN page for a given non-Meraki peer matches what is configured as the local ID on that device.
This firmware version contains important changes required for communications between MX appliances and the AMP and ThreatGrid clouds. Customers utilizing the ThreatGrid integration will need to upgrade to MX 14.56, MX 15.43, MX 16.7, or higher before October 1, 2021. Customers utilizing the AMP-only integration will need to upgrade to MX 14.56, MX 15.43, MX 16.7, or higher before December 1, 2021
Legacy products notice
When configured for this version, Z1, MX60, MX60W, MX80, and MX90 devices will run MX 14.56.
Bug fixes
Corrected an issue that could result in VPN flows being incorrectly reported as active when 1) A previous AutoVPN connection was established, 2) the AutoVPN peer became offline or disconnected, and 3) the AutoVPN peer was configured to operate in high availability (HA).
Stability improvements for MX67(C,W) and MX68(W,CW) platforms
Corrected an issue that resulted in MX appliances incorrectly using their WAN interface MAC address when 1) the MX appliances are configured in high availability, 2) the MX appliances are configured as one-armed VPN concentrators, and 3) traffic was being sourced from the shared virtual IP. MX appliances will now properly use the virtual MAC address in these cases.
Corrected a case that could result in a crash of the process responsible for managing and maintaining non-Meraki and client VPN tunnels.
Resolved an issue where DNS responses directing clients to a content filtering blocked page were improperly forwarded to the WAN network when an MX was configured as a passthrough appliance or one-armed VPN concentrator.
Mitigated an issue that resulted in traffic flows being incorrectly mapped to a secondary WAN interface during the bootup process of MX appliances.
Fixed a rare issue that could result in increased packet loss for traffic destined to or sourced from the LAN on MX64(W) appliances.
Resolved an issue that resulted in Layer 3 firewall rules including FQDNs in the source or destination addresses failing to apply when MX appliances were configured in passthrough mode.
Corrected an issue that resulted in an MX not properly updating the MTU value used for AutoVPN after 1) the MX appliance had established an AutoVPN tunnel with multiple MX appliances, 2) the AutoVPN peer appliances had different MTU values, and 3) the AutoVPN peer appliance possessing the lowest MTU value was disconnected and not reconnected.
Fixed an issue that resulted in communications across non-Meraki site-to-site VPN connections not being subject to configured bandwidth limits.
Resolved a rare issue that could result in highly delayed DHCP responses from MX MX67W, and MX68(C)W appliances.
Resolved an issue that resulted in MX appliances incorrectly forwarding traffic across the site-to-site VPN when 1) the MX appliances operating in one-armed VPN concentrator mode, 2) site-to-site VPN was enabled, and 3) traffic was received on the WAN interface with a source IP address matching the MX’s WAN interface IP. This situation could arise during an unintended routing loop and will now be dropped by MX appliances.
Fixed a case where the non-Meraki VPN service was not stopped when all non-Meraki VPN peers are removed from the configuration.
Corrected an issue that resulted in AutoVPN tunnel status reflecting as disconnected when 1) An uplink failover occurred, and 2) the MX appliance was unable to contact the VPN registry for one than one minute.
Resolved an issue where traffic could be incorrectly dropped under the following conditions 1) the MX appliance was configured to operate in passthrough / VPN concentrator mode, 2) the MX was configured to track clients by IP address, and 3) traffic was sourced from IP addresses 10.128.128.126, 10.128.128.127, 10.128.128.128, 10.128.128.129, 10.128.128.130, or 10.128.128.131.
Resolved an issue where ping reply messages were dropped when 1) an AutoVPN spoke is configured to form a VPN connection with two hubs, 2) a ping request message is sent from a client behind the AutoVPN spoke, 3) the ping request message is destined to a client behind the primary AutoVPN hub, 4) the ping response from the destination client, reached over the AutoVPN connection to the primary hub, is routed back to the AutoVPN spoke via the secondary AutoVPN hub. This happens only in cases where the secondary AutoVPN is configured with a default static route to the LAN.
Fixed a rare issue that could result in MX appliances not forming IKEv2 non-Meraki site-to-site VPN tunnels after the tunnels were previously established and a change was made to the non-Meraki VPN peer configuration.
Security fixes
Known issues
After making some configuration changes on MX84 appliances, a brief period of packet loss may occur. This will affect all MX84 appliances on all MX firmware versions.
Some stability-impacting issues present in MX 14.19 that affect a small population of MX250 and MX450 devices still exist.
Some stability-impacting issues present in MX 14 that affect a small population of MX67(C,W) and MX68(W,CW) appliances still exist.
Some stability-impacting issues present in MX 14 that affect a small population of Z3(C) appliances still exist.
Please note that until certification has been obtained, the Z3C will not be supported on Verizon's network.
World-wide device SKUs of the MX67C, MX68CW, and Z3C units cannot be deployed in North America and North America device SKUs of the MX67C, MX68CW, and Z3C units cannot be deployed outside of North America.
When deployed in warm spare / high availability (HA), MX67C and MX68CW do not support using their cellular connectivity to pass client traffic. In this deployment, the cellular connectivity can only be used for device monitoring or network troubleshooting. This is an expected limitation for these platforms.
MX67C, MX68CW, and Z3C units must be connected to the Meraki Dashboard initially to retrieve an update to allow for proper use of the integrated cellular connectivity. This is most likely to be an issue when bringing the units online for the very first time.
On the MX67(C,W) and MX68(W,CW) platforms, when the MX is providing PoE to a connected device, this information will not be reflected on the Meraki Dashboard.
Once a Z3 has been updated to this firmware version it can only run MX 14.31 or MX15.8 and higher. This is an expected result of updates to the device booting mechanisms and this limitation will not be resolved in future releases.
The DES encryption algorithm is no longer supported for use in formation of VPN tunnels.
Creating VPN tunnels using aggressive mode IKE is no longer supported.
Due to MX 15 regressions, USB cellular connectivity may be less reliable on some modems.
Due to an MX 15 regression, the management port on MX84 appliances does not provide access to the local status page.
Client traffic will be dropped by MX65(W), MX67(C,W), and MX68(W,CW) appliances if 1) The client is connected to a LAN port with 802.1X authentication enabled and 2) The VLAN ID of the port is configured to 16, 32, 48, 64, 80, 96, 112, 128, 144, 160, 176, 192, 208, 224, or 240.
Due to issues still under investigation, Z3(C) appliances are more likely to experience a device reboot when the wireless functionality is being utilized.
If my answer solves your problem please click Accept as Solution so others can benefit from it.
