18.211.2 Out - Promoted to Stable/ Several Fixes

[Mloraditch]

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

• Corrected an issue that resulted in Non-Meraki VPN tunnels persisting on the backup, non-primary uplink after failing back to the primary uplink when the WAN interface used IPv6.
• Fixed an issue that resulted in the VPN status being reported incorrectly for Non-Meraki VPN peers connected via FQDN.
• Resolved an issue that could cause MX appliances upgrading to MX 18.2 from very old, unsupported firmware versions to hang during the upgrade process.
• Corrected a rare issue that could cause upgrades from MX 18.1 to MX 18.2 versions to fail to complete successfully.
• Fixed an MX 18.2 regression that resulted in the link light LED for WAN2 on MX75 appliances failing to light up if WAN2 is the only wired interface in use.
• Resolved a rare issue that could result in data failing to pass over the cellular interface of Z3C, MX67C, and MX68CW appliances, even when the modem was reported as connected.
• Corrected an issue that could result in MX appliances encountering an unexpected reboot when ThreatGrid was enabled.
• Fixed an issue that caused the Non-Meraki VPN service to fail to properly establish IKEv2 tunnels when the MX appliance was acting as the IKEv2 responder and many allowed subnets were configured.
• Resolved several cases that could result in an unexpected device reboot.

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

Known issues status

• This list is being reviewed and updated.

Known issues

• 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.
• MX AutoVPN tunnels fail to generate new connections when the AutoVPN flow has been blocked or filtered unidirectionally by an upstream or intermediary device. This prevents appliances from automatically working around this partially connected state.
• MX appliances may experience unstable eBGP connections when 1) the MX appliance is configured in Routed mode and 2) the MX learns a large number of routes from its eBGP neighbor. This may result in eBGP-learned routes being inaccessible.
• Trusted traffic exclusions will not function on Z4(C) appliances if AMP is configured.
• Due to an MX 18.211 regression, MX75, MX85, MX95, MX105, MX250, and MX450 appliances when configured as Wireless Concentrator for SSID Tunneling and Layer 3 Roaming, will fail to forward return Radius Authentication traffic causing clients to fail to connect to the SSIDs.

[cmr]

The known issues list doesn't look very healthy to me, especially the one regarding SSID concentrator limitations!

[BHC_RESORTS]

@cmr Yeah we won't be able to upgrade to 18.211.2 with that bug in it. Which is annoying as our firmware is now showing a warning for July 6th. And i have no desire to go on the untested 19 train.

[Nightstick]

i don't want to be the first guinea pig to try this "stable".

[FRover]

Is this ever going to be fixed??

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

[harmankardon]

I am in the same boat. It's incredibly frustrating that such a key feature has been broken for so many firmware versions.

[FRover]

Being stuck on 1616.9 and behind on security updates is very frustrating because there is no guarantee that our 4G won't function on dozens of devices in the field. 

[SPieroni]

I have several MX84's which are now Legacy devices.  Meraki has auto scheduled these devices to be upgraded.  Since these are Legacy devices and the release notes state they will remain at 18.107.10 what changes can I expect if any?

[Lauzon_C]

Just security patches. No new features.

[SPieroni]

Thank you!

[MSakr]

Hi

I am not able to upgrade from 18.211 , my options are greyed out

[CyberDingo]

We are having an issue, and I wanted to see if anyone else if experiencing a similar issue: not sure if it is related.

We updated all our SD-WANs to 18.211.2 recently. We have an issue with users experiencing slow connection speeds to load webpages. After testing with packet captures, we are seeing a lot of "TCP Retransmission" "TCP Dup ACK" "TCP Out-of-order" that I am assuming is causing the slow speeds. 

I will test rolling back the firmware this evening and test the packet capture again to see if it makes any difference.

[CyberDingo]

Discovered this was because of an error on and upstream ISP router. Please, disregard these comments.

[zeestrat-nina]

We are running into an issue that seemed to show up on firmware 18.211.2.
L3 firewall outbound allow rules with FQDN in destination seems to now only hit sometimes and mostly skip the allow rule.
The new Firewall Log confirms this showing it is hitting the allow only every few requests.
Does not matter if FQDN has single or multiple A records.

Anyone else seeing this as well?

[StefanK]

We made an update from version 18.107.2 to 18.211.2 and since then the phase 1 handshake failed after the 5th packet. For additional reference there is a FortiADC Loadbalancer in front of the Meraki. We already performed a lot of different tests (different SNATs, DNAT), but what we see in Wireshark is, the first 4 packets are always correctly handled between the LB and the Meraki in a single UDP-stream. Then the 5th packet is send from the LB to the Meraki in a new UDP-stream and the Meraki is answering with an ICMP TTL exceeded packet, causing the IPsec VPN to fail. We also noticed, that when there are no active sessions on the Meraki, the first user, who is trying to establish a VPN tunnel is successful. Any additional attempts are resulting in the ICMP TTL exceeded error.

Is this a bug in this version or does it interfear with any non-optimal setting on the LB? The LB is simply configured in Layer4 mode with UDP profile and doing a SNAT. With the old software version everything runs fine without any changes on any other component. Any ideas how to further troubleshot this?

Thank you!

Regards,

Stefan

[RaphaelL]

Known issues - july 12th update

• Due to a regression MX75, MX85, MX95, MX105, MX250, and MX450 are unable to process NAT-T IPSEC VPN connections when the source port is not 4500.
• An issue has been discovered that can cause Z3 and Z3C to stop broadcasting the WiFi SSIDs.

[Jabettan]

We updated from 18.107.2 to 18.211.2 on 2024-07-05
This is on an HA pair of MX68.

There were no issues at first but over time the connection got progressively worse.

On both WAN1 and WAN2 we were getting an additional 300ms of latency.

Jumping anywhere from between 5-100mbps on both upload and download on a pair of 500mbps circuits.

When removing all downstream devices except for a single laptop connected to a test port the latency and bandwidth improved a bit but nothing close to what we were getting prior.

Called support and downgraded back to 18.107.2 and all issues disappeared.

As per-support we were at 100% utilization.

Post downgrade we were under 40%

We will wait a few days then path to 18.107.10

[RaphaelL]

You should go to 18.107.11 which is the latest.

[Jabettan]

As per the Legacy products notice for version 18.107.11:

• This firmware version is only available for MX64(W), MX65(W), MX84, MX100, and vMX100 appliances. Any other devices configured to this firmware version will not upgrade.

The devices we are using are not in this list.

Regards