Thanks again Bruce, so is it right to say that MXes first try to establish VPN tunnels on a specific WAN port using its public IP address and if it is the same with the destination then they use private IP? Is there any public document that describes this behavior?   Suppose that the MPLS has its own Internet exit, the public IP would also change on the MPLS path. In that case how could the Meraki Cloud know that it should use private IPs on that path to form VPN tunnels inside the MPLS?   For the MX spoke limitations, I got it, it's simply routing 😆 ... View more

Bruce thanks for your explanation, but it brings me to other doubts 😆 In a one-arm deployment, we have the MXes that work as hubs connected to the L3 Core with only one WAN port (correct me if I'm wrong), configured with a private IP address of the internal transit subnet. Internet Tunnel: The MXes register to the Meraki Cloud through the Internet cloud (because the Firewalls have a default route toward the Internet CPEs), so the Cloud learns the private IP, the public IP, and the public port used by the MXes on that path. MPLS Tunnel (This is tricky for me to understand): If the MXes need to reach the Meraki cloud also over the MPLS path we need an "Internet exit" in the MPLS cloud, but MPLS is supposed to be a private L3VPN usually isolated from the Internet (at least in my country ISPs may not support this configuration). 1 - How does the cloud learn about the MPLS path if we don't have an Internet exit in the MPLS cloud? 2 - Suppose that the ISP provides that internet exit (and we load balance the default route between the two paths), How would be the VPN tunnel created over the MPLS network (using private IP addresses)? MX spokes limitations: You said: "If you do single arm in the branch you’ll only get one VPN tunnel via one path - so no SD-WAN and no load balancing/performance routing of traffic, and no security features, so you lose most of the benefit of the MX solution". So I suppose there are limitations based on which deployment mode you choose, because we may have the same topology in the spokes (a firewall couple at the edge that we don't want to touch with an L3 Core behind), but spokes would not be able to form multiple tunnels. Did I understand wrong?   Many thanks Bruce for your support 🙂   ... View more

Hi Bruce and thanks a lot for your reply.   1 - How can you tell the MXes that there are two different paths (Internet and MPLS) when they are placed with a single-arm behind the L3 Core? Do they need also to access the Meraki cloud directly from the MPLS (so with a different public IP than the Internet connection - I suppose the Internet path is enough)? Is there any public document that describes that behavior?   2 - If there is already an Internet connection in the branch shouldn't the MXes use that to access the Meraki cloud? Do they need to do it going through the HQ? 3 - So there are limitations when you deploy MXes as spokes, are they documented somewhere? If I have dedicated firewalls in the branches and I want to keep them at the edge of the network and place the MXes behind, how can I do it? If I lose SD-WAN with a single-arm deployment in the branch, the only way to implement it is by configuring the MXes in Routed Mode and therefore with NAT enabled? The No-NAT feature is still in Beta?   Actually, the third point has a lot of questions 🙂   Thank you very much, Davide ... View more