MX 15.17 firmware released

[cmr]

New v15 firmware, but with a rather alarming known issue, can anyone add some colour to this...

Security appliance firmware versions MX 15.17 changelog

Bug fixes

• Corrected an issue that could result in improper STP topologies forming when MX250/450 were deployed in a high availability topology with multiple downstream switches
• Resolved several rare issues that may have contributed to the likelihood of a device reboot occurring on Z3(C) platforms
• Corrected an MX 15.14 regression that could result in the process responsible for managing system time crashing
• Fixed an issue that could result in AutoVPN traffic improperly following a default route over other, more specific routes when the default route was learned via IBGP
• Corrected an issue that resulted in default routes learned via EBGP not being advertised to IBGP peers
• Fixed an issue that could have resulted in mesh beacons being sent by MX and Z units with integrated wireless
• Resolved a rare issue that could result in an associated wireless client not being able to pass traffic properly
• Resolved a rare issue that could result in MX67(C,W) and MX68(W,CW) appliances becoming inoperable after a device reboot occurred

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
• 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.
• When MX67(C,W) and MX68(W,CW) units are deployed in warm spare / high availability (HA), rebooting the spare appliance may cause a disruption of client connectivity for 10 or more seconds.
• After making some configuration changes on MX67(C,W) and MX68(W,CW) appliances, a period of packet loss may occur for 10 or more seconds.
• For a brief period of time upon boot, MX67(C,W) and MX68(W,CW) platforms can become bridged. This increases the likelihood of network loops forming in topologies with multiple inter-connected network devices for this brief period of time.
• 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.
• Due to an MX 15 regression, client VPN users cannot communicate across non-Meraki VPN tunnels
• The MX may fail to forward traffic for clients in subnets for which source-based routes are configured
• 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
• Due to MX 15 regressions, the MX may not be able to form non-Meraki site-to-site VPN connections to peers behind a NAT
• Due to issues still under investigation, there are significant performance regressions.

Other

• Improved the scalability and reliability of downloading content filtering lists.
• Improved the reliability of file disposition lookup requests sent to the AMP Cloud.

[NetworkGuy9]

I wouldn't say it's alarming since it's in beta. Now if that bug still exists when it's in release candidate status then we have some worrying to do but it'll likely be fixed long before that.

[cmr]

@NetworkGuy9  for Meraki the descriptions aren't used the same way as other vendors, see this link Meraki Firmware Release Process where what Meraki call Beta is supposed to be production ready, just not tested much out in the wild.  I am aware that the 15.x branch is somewhat experimental but the previous 16(!) versions have not had such a wide ranging caveat....

We use MXs for SDWAN and for that you do really benefit from v15.x but we'll be skipping this point release!

[cmr]

So 15.18 has now been released with the below fixes, but it still contains the general performance known issue mentioned above, slightly more alarming is that the known issue has been back ported into prior releases...

Bug fixes

• Resolved an issue that could result in non-Meraki VPN and client VPN tunnels failing to form if certain characters were used in the pre-shared key.
• Performed some tuning of packet buffers on MX250 and MX450 appliances. This should improve the consistency of TCP performance when between a 10Gbps WAN interface and a 1 Gbps LAN interface.
• Resolved an issue that could result in device reboots of MX84, MX250, and MX450 appliances.
• Corrected an issue that could result in a device reboot when ThreatGrid integration was enabled.
• Fixed several issues that could result in a device reboot when AMP was enabled.

[Dartanian14]

Any known issues with 15.18 causing the VPN to break for Windows 10? We have 2 MX100s setup with RADIUS for MFA.

VPN works fine connects to the MX on 14.x. Connect leads to username and password, then verification goes and a MFA push notification hits, you accept and you're connected.

VPN doesn't authenticate at all on 15.18 on the other MX. Hit connect, it asks for username and password, enter it and it just spins CONNECTING eventually bombing out saying their was an L2TP issue and nothing on the DC shows any sort of attempted authentication occurred. 

I even dumbed down the shared secret on the RADIUS server since there is some weird issues with that otherwise everything is identical. The common denominator at this point is the MX with the newest firmware isn't working,

[cmr]

15.20 is the latest now there are some VPN fixes in it but they pertain to communication after connection.  I'd upgrade though as the performance regression is addressed