The Meraki MX84 firewalls are subject to the Cisco Clock Signal Component issue that affects many firewalls and routers. With a typical Cisco device, we would copy the config from the old device and put it on the new device. Since Meraki devices are cloud managed, copying the config in this way is not possible. I called Meraki tech support and they said this could be accomplished by using a process called a “MX Cold Swap”. Meraki documents that process here: https://documentation.meraki.com/MX-Z/Other_Topics/MX_Cold_Swap_Replacing_an_Existing_MX_with_a_Different_MX
After performing the MX Cold Swap, everything seemed to be working, until we tested email. Inbound and outbound emails were not being delivered and email was queuing on the Exchange server. Since our visibility into the Meraki devices is limited to the web portal, I called Meraki tech support for assistance troubleshooting. After troubleshooting, we found that that main IP address was working, but the other public IP addresses that were NAT’d were not working. We tried rebooting the ISP’s equipment onsite to clear any MAC address tables, but that did not solve the issue. The Meraki tech support engineer found an article in their knowledge base that describes this issue: https://documentation.meraki.com/MX-Z/NAT_and_Port_Forwarding/1%3A1_NAT_Rules_not_working_properly_after_installing_MX.
The solution is to log into the local status page of the Meraki firewall and set the main IP to the NAT’d IP that is not working. This adds the NAT’d IP addresses to the ARP cache on the upstream routers. After a few seconds, you change the main IP address back to the correct address. Repeat for any other NAT’d IP addresses. This solution worked for the NAT’d IP addresses that originally were not working.