Site-To-Site VPN over MPLS

carl222
Here to help

Site-To-Site VPN over MPLS

Hi,
We have site-to-site VPNs configured as a Hub and Spoke topology.

https://documentation.meraki.com/MX/Site-to-site_VPN/Configuring_Site-to-site_VPN_over_MPLS

 

All our branches (spokes) have WAN1 (MPLS Link) and WAN2 (Broadband Link on site).

 

Our MPLS have an Internet breakout at our Data Center with public IP of 11.22.33.44. Our hub is also in our Data Center with public IP of 11.22.33.45 (same subnet, different IP).

Based on the Site-to-site VPN over MPLS documentation, my understanding is that if we want to build a tunnel over MPLS (by using the PRIVATE interface IP address of our hub and our spokes), the source public IP have to match between our hub and our spokes.

 

In this situation, the hub has 11.22.33.45 and all spokes have 11.22.33.44. Because of that, I'm wondering if the tunnels are built correctly on our MPLS link... Wouldn't be better if the WAN1 (MPLS) tunnel was built using private IPs ? Now it looks like the WAN1 (MPLS) tunnel is built between 11.22.33.45 and 11.22.33.44. Traffic is going upstream to the edge of our DC to come back in after. 

 

Thanks!

 

5 REPLIES 5
cmr
Kind of a big deal
Kind of a big deal

@carl222you are correct, you need to have the same public IP on both in order that the SD-WAN create tunnels with the private IPs.  We have had this setup running for about a year with two MPLS WANs and it works well.  Can you not make the traffic from the hub use the same IP as the spokes, it only has to use it for the destination IP addresses that Meraki use to determine the public IP of the device?

@cmr Thanks for the reply!

 

I see, it should be possible to make that change on the upstream firewall where NAT is happening.

 

We've been receiving 100+ alerts everyday from site-to-site VPNs flapping non stop. I opened a ticket, they switched all our networks to new VPN Registry servers, still receiving alerts. Last weed-end, long story short, our MPLS circuit couldn't reach the Meraki Cloud from our Internet breakout at our DC so all our WAN 1 were in a Failed state. VPN tunnels were also built on WAN 2 (active-active) at every sites and guess what... NO alerts at all. Nothing in the event logs, stable like never before.

 

My guess is that the tunnels built on our MPLS using different public IPs like mentionned before is just unstable.

 

What do you think ?

 

Thanks again

cmr
Kind of a big deal
Kind of a big deal

@carl222 we have only minor flap issues, usually only caused by overloaded tail circuits and they don't impact the users.  In your setup, every SD-WAN connection over the MPLS has to get to the DC, then out to the internet, then back in via the same circuit and possibly the same firewalls.  I'd expect this causes significant load and delays, also unless you have fixed the ports, as all the spokes are on one IP and the hub on the other, I wouldn't be surprised if the firewall NAT wasn't overly happy, hopefully not to the point where it thinks it is being attacked!  If you can change it then I definitely would 😎

@cmr Wow, we had major firewall problems too last week. Our hub is in the DMZ so it has to go through that firewall every time remote users need to access our servers... On top of that, like you said we don't have fixed ports and traffic is going out and in again... No wonder we're experiencing slowness at every branches.

 

I'll change the public IP of the hub to match the spokes and I'll move the hub to the Core L3 with a 10Gb SFP connection. Our MPLS traffic arrives at the Core L3 switch directly so it will take off some load on our poor firewall 😄

 

This should fix our problems..

 

Thank you again!!!!

@cmr If you don't mind, how does your setup looks like ?

 

Do you have your hub in the DMZ ?

 

Are you using OSPF on your hub to advertise remote VPN subnets ?

 

What are your settings in the SD-WAN/Traffic Shaping page (Load-Balancing, Flow preferences, etc) ?

 

Thank you, you're awesome 😄

Get notified when there are additional replies to this discussion.
Welcome to the Meraki Community!
To start contributing, simply sign in with your Cisco account. If you don't yet have a Cisco account, you can sign up.
Labels