New MX 16.9 beta release coming (stable release for MX95 and MX105)

[cmr]

Security appliance firmware versions MX 16.9 changelog

Important notice

• This is an early-stage beta version for the MX 16 release. Due to this, we recommend taking additional caution before upgrading production appliances. Where applicable, MX 15 or MX 14 releases will provide a more stable upgrade alternative.

Legacy products notice

• When configured for this version, Z1, MX60, MX60W, MX80, and MX90 devices will run MX 14.56.

Supported products notice

• This is the latest stable release version for the MX95 and MX105 appliances. This release is considered beta for all other devices.

Bug fixes - VPN

• 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.
• Corrected an issue where DHCP traffic being routed across AutoVPN would be dropped on MX appliances configured to operate in passthrough mode if the source port of the DHCP traffic was 67 and the destination port of the traffic was 68.
• 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.
• Update the AnyConnect VPN service

Bug fixes - other

• Corrected a rare issue that could result in MX appliances failing to route traffic properly when BGP was enabled and a BGP routing change occurred.
• Resolved a rare issue that resulted in routes not being properly installed in the routing table when many routing changes were occurring.
• Fixed an issue where MX appliances would incorrectly report DNS was misconfigured while using a cellular WAN uplink.
• Security updates

Known issues - all

• Group policies do not correctly apply to client devices
• MX IDS security alerts are not detected for AnyConnect VPN traffic
• BGP-learned routes may not be properly reflected in the Route Table page on the Meraki Dashboard, despite BGP and packet routing operating correctly.
• Due to MX 15 regressions, USB cellular connectivity may be less reliable on some modems
• There is an increased risk of encountering device stability issues on all platforms and across all configurations.

Known issues – MX84,MX100

• Significant performance regressions for VPN traffic may be observed on MX84 and MX100 appliances
• 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
• Due to an MX 15 regression, the management port on MX84 appliances does not provide access to the local status page

Known issues – MX67,MX68,Z3

• 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.
• 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.
• 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.
• Some stability-impacting issues present in MX 14 that affect a small population of MX67(C,W), MX68(W,CW) and Z3(C) appliances still exist.
• Please note that until certification has been obtained, the Z3C will not be supported on Verizon's network.
• Z3(C) appliances that are upgraded to MX 16 versions cannot directly downgrade to MX 14 releases. They must first downgrade to an MX 15 release.

[rhbirkelund]

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.

Some times, I'd really wish for the opportunity to get more details on bugs and their fixes....

[rhbirkelund]

Just as much as the long standing;

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.

[Iridium79]

Well I just i found out they will not be fixing the LLDP/CDP Issue on the MX250 and MX450.  Looks like the developers dont find it a real world impact.   Guess I will be pulling the plug on Meraki.   This is complete garbage.  Never will i recommend another meraki product to any of our customers, if thats how they treat their flagship models.  HALF BAKED!

[JohnT]

I upgraded from 16.4 to 16.9 and now I'm getting an "Untrusted Server Blocked" error message when I try to connect with AnyConnect.  The dynamic DNS name appears to be the same so I'm not sure what would cause that.  Maybe something went sideways with the certificate during the upgrade.  I'll probably open a support ticket.

[OVERKILL]

Yep, I upgraded two sites last night and now I'm getting this as well. @Bsalami may be able to get this resolved quickly I'm hoping. 

My sites were running 16.6 and 16.7 respectively. 

It appears it shifted from an an external CA-issued cert to a self-signed one.

This is what we get now:

Unit running 16.9

This is from a unit running 16.7:

Unit running 16.7

[OVERKILL]

Just note that rolling back to 16.7 on one of the devices didn't fix the issue, it has a self-signed cert again. 

[KarstenI]

You get out of this situation by changing the dynamic hostname to something else, wait some time, and then back to your original name.

[OVERKILL]

Have you tried this with 16.9? I ask because, as per the separate thread I made on this, I can't even get AnyConnect to come up or resolve on another MX I have that I upgraded. I feel this may be a bigger issue on the certificate issuing and hostname integration side of things. I've opened a ticket about it. 

[KarstenI]

I tried 16.9, ran into the same issue (changing hostnames did not help), rolled back, and after the next change of the hostname everything was fine again.

[OVERKILL]

OK thanks. I'll try that after hours on them if we don't get this resolved today. 

[Bsalami]

Please open a case with Meraki Support to upgrade to 16.8. We are investigating the AnyConnect cert issue reported on 16.9.

[OVERKILL]

I performed what was indicated by @KarstenI on the MX I rolled back to 16.7 and it worked in terms of creating a valid certificate again. 

I forwarded this thread to the guy I was speaking with on the ticket, but I haven't heard anything back yet, but at least the error is gone.