CoNetrix

Blog: Meraki

We recently moved a customer from a datacenter at one of their locations to a large datacenter in the Dallas/Ft. Worth area. One of the devices we moved was a Meraki MX84 being used as a VPN concentrator. A VPN concentrator works by extending the network the VPN concentrator is on to the access points. Basically, wireless clients at all locations get an IP address on the same layer two network. This is important for a few reasons. First, the VPN concentrator needs to be in it's own VLAN/DMZ. Second, something on the layer two network the VPN concentrator is connect to needs to be handing out DHCP addresses. In our case, we used a Fortigate UTM to run the DHCP server for that subnet. Third, traffic needs to be allowed outbound to the Internet from all clients on the VPN concentrator layer two network so clients can connect to the Internet. The traffic is tunneled from the access points to the VPN concentrator, so the traffic does not intermix with the normal network traffic.

One of the issues we had was that the access points would not create the tunnel back to the VPN concentrator. After talking to Meraki support, we found that the issue was that the access points and the VPN concentrator would not connect to each other if their public IP address was the same. This does not work because Meraki uses the same technology to build the VPN from the MX to the access points as they use to build a VPN mesh between MX devices. Our devices were both using the default overloaded outbound NAT rule, so they were coming from the same public IP address. The solution is to make the MX come from a different public IP address, which can be accomplished via an inbound and outbound NAT statement. After we made this change, the access points connected to the VPN tunnel and wireless began to work.

One other thing to note is that the access points will not broadcast SSIDs if the VPN to the concentrator is not up when configured to tunnel traffic through a VPN concentrator. This can be helpful when troubleshooting wireless when there are not clients at the location of the access points.

 

 

VPN, wireless, Meraki,
 

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.
Networking, Meraki,