New MX 16.12 beta release firmware - fixes VPN performance issues on MX84/MX100 (and a few others)

cmr
Kind of a big deal
Kind of a big deal

New MX 16.12 beta release firmware - fixes VPN performance issues on MX84/MX100 (and a few others)

Security appliance firmware versions MX 16.12 changelog

Important notice

  • This is a 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.
  • While Meraki appliances have traditionally relied on UDP port 7351 for cloud communication and TCP ports 80 and 443 for backup communications, with MX 16 we are beginning a transition to using TCP port 443 as the primary means for cloud connectivity. In order to ensure proper connectivity to the Meraki cloud after this upgrade, please ensure that traffic using TCP port 443 between 209.206.48.0/20 is allowed through any firewalls that may be deployed upstream of your Meraki appliances.
  • HTTP proxy, which allows default management traffic from MX appliances to be sent through a proxy, is deprecated on MX 16 and higher firmware versions.

Legacy products notice

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

Bug fixes

  • Resolved an issue resulting in “Ethernet Port Carrier Change” Event Log message containing the incorrect port numbers for MX75 and MX85 appliances.
  • Corrected an MX 15 regression that resulted in communications to the VPN registry service failing on the WAN2 interface when the MX appliance was configured to use manual NAT traversal for AutoVPN site-to-site VPN connections.
  • Resolved an MX 16.4 regression that resulted in MX appliances that were configured to 1) operate as an in-line passthrough or a one-armed VPN concentrator and 2) were configured to operate in high availability (HA) mode using an incorrect MAC address for management and connection monitoring traffic.
  • Fixed a rare issue that could result in site-to-site VPN firewall rules not correctly applying when AutoVPN peer’s participating subnets changed.
  • Corrected an issue that resulted in content filtering not blocking web content for AnyConnect VPN clients.
  • Resolved an issue that resulted in too many Event Log messages being generated on MX68(C,CW) appliances when 802.1X port authentication was configured.
  • Corrected an issue that could result in clients being unable to associate wirelessly to MX65W appliances in rare cases.
  • Resolved an MX 16.7 regression that resulted in traffic not being routed correctly for LAN traffic where the LAN subnet overlaps with the subnet on one of the MX’s WAN interfaces.
  • Removed the “safe mode” configuration on the device local status page for MX and Z appliances. These configurations are only necessary for MG appliances.
  • Corrected an MX 16 regression that resulted in significant performance degradation for VPN traffic may be observed on MX84 and MX100 appliances.
  • Resolved a rare issue that could result in issues booting up after firmware upgrades for MX100 appliances.
  • Updated the AnyConnect VPN service
  • Stability improvements for Z3(C), MX250 and MX450 appliances.

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
  • 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.
  • Group policies do not correctly apply to client devices
  • 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.
  • BGP-learned routes may not be properly reflected in the Route Table page on the Meraki Dashboard, despite BGP and packet routing operating correctly.
  • There is an increased risk of encountering device stability issues on all platforms and across all configurations.

Other

  • MX appliances operating as AutoVPN hubs will no longer fully reset tables used to track VPN flows when AutoVPN peers are added or removed. In most cases, this is a small optimization; but, in very rare cases, this change can prevent traffic disruption that could occur briefly after AutoVPN peers were added or removed from the configuration.
2 Replies 2
DarrenOC
Kind of a big deal
Kind of a big deal

Anyone any ideas as to why we’re moving away from the UDP port 7351 for the primary Meraki cloud comms to using the backup as the Primary (TCP 443, 209.206.48.0/20)?

Darren OConnor | doconnor@resalire.co.uk
https://www.linkedin.com/in/darrenoconnor/

I'm not an employee of Cisco/Meraki. My posts are based on Meraki best practice and what has worked for me in the field.
cmr
Kind of a big deal
Kind of a big deal

@DarrenOC perhaps it is because too many people don't know how to configure firewalls and the other commonly open option of 80 wouldn't be so great... 🤔

Get notified when there are additional replies to this discussion.
Welcome to the Meraki Community!
To start contributing, simply sign in with your Cisco account. If you don't yet have a Cisco account, you can sign up.
Labels