MX 18.210 firmware

[jimmyt234]

A lot of fixes in this one... who's going first?

Security appliance firmware versions MX 18.210 changelog

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

• Resolved an MX 18.208 regression that resulted in the firewall logging live tool stopping unexpectedly on MX75, MX85, MX95, MX105, MX250, and MX450 appliances.
• Fixed an MX 18.2 regression that resulted in vMX appliances improperly showing references to a WAN2 interface on the Appliance Status page.
• Corrected an MX 18.1 regression that could result in MX95, MX105, MX250, and MX450 appliances improperly duplicating multicast packets.
• Resolved an MX 18.1 regression that resulted in MX95 and MX250 appliances failing to send CDP or LLDP messages.
• Fixed an MX 18.2 regression that could result in traffic not being properly routed for clients when No-NAT was configured.
• Corrected a rare issue that could cause Event Log messages to be lost while the MX appliance was applying configuration updates.
• Corrected a rare issue that could result in MX75, MX85, MX95, MX105, MX250, and MX450 appliances failing to forward traffic from some clients.
• Fixed an MX 18.2 regression that resulted in MX75, MX85, MX95, MX105, MX250, and MX450 appliances inconsistently forwarding traffic to clients with a 1:1 NAT rule configured.
• Resolved an MX 18.2 regression that could result in ThousandEye’s Path Visualization failing for traffic routed over AutoVPN on MX75, MX85, MX95, MX105, MX250, and MX450 appliances.
• Fixed an MX 18.2 regression that resulted in MX appliance improperly dropping traffic from non-Meraki VPN peers when that traffic was received over a PPPoE uplink.
• Fixed a rare case that could result in non-Meraki VPN tunnels failing to form.
• Stability improvements for MX75, MX85, MX95, MX105, MX250, and MX450 appliances.
• Corrected an MX 18.2 regression that caused MX appliances configured in passthrough mode to be unable to establish VPN tunnels to tunneled SSIDs configured on MR devices.
• Corrected an issue that could result in MX75, MX85, MX95, MX105, MX250, and MX450 appliances configured in VPN concentrator mode failing to forward traffic received from AutoVPN clients.
• Fixed an issue that could result in MX250 and MX450 appliances improperly forwarding LLDP and BPDU frames from LAN out the WAN interface(s) during the bootup process.
• Corrected an issue that could result in MX65(W), MX67(C,W), MX68(W,CW), MX75, and MX85 appliances losing static IP configuration after entering into failsafe mode.
• Resolved a rare issue that could result in HTTP file downloads failing when AMP was enabled.
• Stability improvements for MX67W and MX68(W,CW) appliances.
• Corrected an MX 18.1 regression that resulted in VPN status information about WAN2 not being properly reported. This resulted in the information on the VPN status page being incorrect.
• Corrected an MX 18.107.7 regression that could cause MX appliances that 1) have Mandatory DHCP enabled and 2) are rebooted to encounter severe disruptions to network traffic.
• Fixed a rare issue that could occur during firmware updates that resulted in MX appliances unexpectedly having configurations that were out of date.
• Resolved an MX 18.2 regression that resulted in MX appliances not honoring flow preferences for Internet traffic when the preferred uplink was cellular. Devices operating under the SD-WAN+ license were not affected.
• Stability improvements for MX75, MX85, MX95, MX105, MX250, and MX450 appliances.

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.9.

Known issues status

• This list is being reviewed and updated. Many existing issue reports have not been confirmed to affect MX 18.2XX firmware versions.

Known issues

• MX appliances that have configured adaptive policy may encounter frequent connectivity state changes for AutoVPN tunnels.
• Devices manufactured by Ingenico may experience an unstable physical Ethernet connection when directly connected to MX68(W,CW) appliances.
• Due to rare issues, MX250 and 450 appliances may encounter unexpected device reboots.
• The Non-Meraki VPN service may fail to properly establish IKEv2 tunnels when the MX appliance is acting as the IKEv2 responder and many allowed subnets are configured.
• 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.
• Due to an MX 18.2 regression, MX75, MX85, MX95, MX105, MX250, and MX450 appliances will fail to form AutoVPN tunnels with other MX appliances via their LAN interfaces.

Other

• Added support for reporting CellID on the local status page for Z4C appliances.
• Added support for configuring PPPoE uplinks without a password on the device local status page.
• Added improved input validation on the device local status page when configuring the gateway IP address for WAN interfaces.

[cmr]

Me of course!  Just applied it to a Z3 that was running 18.208.1...

[RaphaelL]

Months and months after the release of MX18 and cellular is still broken... 

• 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.

[ITSDigital]

Upgrading our test MX75 with this version to see how it fares.

[TyShawn]

Just pushed this to an MX75 and setting up an upgrade to MX68 for later tonight. 

[CptnCrnch]

Just went through the upgrade. No issues until now!

[DMD]

Can you elaborate more?

[thomasthomsen]

Only issue here so far is one site with a HA pair of MX105's where they cant seem to upgrade correctly.

All other sites , 20 - 30 with different MX models seems just fine.

The issue with the MX105s we can clearly see on the "connection" graph. Every two hours "red", for a short while. - And of course loss of connection for users.

Support says that maybe some files on the MX are not being purged.

Suggested we try to upgrade to latest 18.1 and then to this 18.2, else reset devices for a proper "clean up". (I dont know when we can have the next service-window on that site, but I will try to update this when that happens)

[DMD]

We have loaded this on our DEV firewall and a couple sites as of yesterday.   We are waiting to perform on the larger MX450 series in HA pair that has been painful for a long time on that series.  Would like to know if anyone else loaded it on their bigger series yet and any issues reported.  NAT rules failing were a big one for us.   

[Scott11]

I'm fighting NAT 1:1 rule failure on a an MX250 right now, and 18.210 didn't seem to help any over any older firmware.

Our problem:

public IPs (not actual, but close representation)
 WAN1
  10.0.0.1/28 gateway
  10.0.0.2 main IP
  10.0.0.3 secondary IP for certain traffic NATed to 192.168.0.11 (this works perfectly on legacy non Meraki router)
 WAN2
  11.0.0.2 main IP

- 1:1 NAT setup for LAN IP 192.168.0.11 to 10.0.0.3 port forwarding port 80 for non-secure informational data.
- of course normal port forward doesn't do anything since the traffic is not incoming on 10.0.0.2
- zero traffic allowed to or from 192.168.0.11 with 1:1 NAT turned on for 10.0.0.3
- outbound only traffic is good from 192.168.0.11 with no NAT or 1:MANY NAT (tried 1:MANY just for fun.) but still no incoming traffic allowed.
- Contacted ISP to clear ARP tables, still no traffic incoming.

With input from Meraki Support, we tried a number of scenarios, including messing with traffic shaping, and flow preferences.  Very confusing as to why with NAT there is no incoming traffic allowed no matter what inbound ports are defined to allow traffic from a non-primary IP that still within the subnet.  Seems like a serious Meraki bug that needs attention.

[Scott11]

I may have found out something about the 1:1 NAT.  Apparently the 1:1 NAT will not even try to work if the destination is not in the ARP table of the Meraki.  And, in my case the destination device didn't seem to fill the ARP table in my short testing window.  After trying another destination device, it started working about 24 hours where it did not initially upon setup.  Very strange it takes so long to update the ARP table.

[jotech]

We just upgraded from 18.107.2 to 18.210 on our MX75 and immediately noticed that the IPv6 uplink is no longer working. I can get our static IPv4 address on the same uplink, but v6 is stuck in 'Failed' state.

It's not urgent as we don't use it, and I can't say if it's our ISP or not. It just started happening after the update.