Non Meraki site-to-site VPN with MG21 as WAN issue

Solved
Roger_Beurskens
Building a reputation

Non Meraki site-to-site VPN with MG21 as WAN issue

Hi,

 

I'm setting up de MG21 for the first time and i'm running into an issue.

Before asking support I wanted to ask if anybody here experienced the same.

 

The setup we have is MX67 firewall and a MG21 as secunday WAN.

 

The enviroment of the customer is running some other MX67c's in the field and a non meraki firewall in the datacenter (Sophos UTM virtual).

 

Using a fixed line on the MX67 everything works like it should be, autovpn to the other meraki locations and a non meraki site-o-site to the datacenter, just like the other 2 locations.

Doesn't matter if we use WAN1 or (converted) WAN2 on the firewall, it works flawlessly.

Tunnel comes up and I can reach the servers in the DC.

 

When i change the fixed line for an MG21 I get the next behavior.

 

- Everything on interne reachable

- Meraki Auto VPN works perfect to the other Meraki sites, everything is reachable

- Non-Meraki VPN tunnel comes up, phase 1 and 2 SA is up and running, but no traffic is possible between the subnet behind the MX67 and the DC.

 

Doesn't matter if the MG21 is connected to WAN1 or WAN2.

 

Anybody got a clue?

 

 

1 Accepted Solution

Found the issue, and created an other one wih this solution 😉

 

NAT-T was disabled on the non meraki peer in the DC

 

we already had 2 meraki locations with a fixed line working over a site-to-site for some months without a problem.

 

Funny thing is, when enabling NAT-T on the Sophos UTM, everything works for the connections via the MG21 but the other tunnels are unstable...

 

Disabling NAT-T at the datacenter solved the issues for the 2 fixed meraki sites according to the customer.

What worries me, is that I still see the SA expiring after 3 minutes for these 2 fixed sites in the meraki logging even though the timers are at 28800 and 3600....

 

Weird things happening..

 

In the mean while, Meraki AutoVPN is still working as a charm.

To bad there is still no vMX available for vmware as we have a lot of customers running on a IaaS platform..

 

I've asked Meraki Support if they changed anything in the background after i asked them for help.

I'll keep this port updated when i know more.

View solution in original post

9 Replies 9
PhilipDAth
Kind of a big deal
Kind of a big deal

My personal guess is firewalling by your cellular data provider, or carrier-grade NAT.

 

Find out if there are any APNs offered by your carrier that don't have a firewall.

That was also an idea i had... but why would the tunnel come up completely than?

i would expect it would be able to complete phase 1 of 2.

 

I've got an other simcard from other provider for testing today so i hope this would solve it.

>That was also an idea i had... but why would the tunnel come up completely than?

 

Lets say they use a 5s UDP timeout (I've seen 2s!).  If your VPN can come up within that time then it will complete building, but once the UDP NAT timeout expires the prior path for transferring data is gone.  The VPN is now up but dead.

 

There are other possibilities as well.  Carrier-grade NAT can break things in many ways.

Hi,

 

Got the simcard of the customer itself..

It's a corporate sim ( Dutch KPN ) with the correct APN setup.

 

With the default APN (internet) it was completely firewalled so the mg21 didn't even connect to the meraki cloud portal.

 

The correct APN ( advancedinternet) everything works except the non Meraki site-to-site.

Autovpn works like a charm...

 

As i'm end of options i'll ask Meraki support if they maybe can see a bit more on the mg or mx what's happening.

 

 

Found the issue, and created an other one wih this solution 😉

 

NAT-T was disabled on the non meraki peer in the DC

 

we already had 2 meraki locations with a fixed line working over a site-to-site for some months without a problem.

 

Funny thing is, when enabling NAT-T on the Sophos UTM, everything works for the connections via the MG21 but the other tunnels are unstable...

 

Disabling NAT-T at the datacenter solved the issues for the 2 fixed meraki sites according to the customer.

What worries me, is that I still see the SA expiring after 3 minutes for these 2 fixed sites in the meraki logging even though the timers are at 28800 and 3600....

 

Weird things happening..

 

In the mean while, Meraki AutoVPN is still working as a charm.

To bad there is still no vMX available for vmware as we have a lot of customers running on a IaaS platform..

 

I've asked Meraki Support if they changed anything in the background after i asked them for help.

I'll keep this port updated when i know more.

Little last update..

 

upgrading the MX's in the full network from MX14.40 to MX15.33 Beta also solved unstable non meraki site-to site connections on the fixed line locations.

Meraki support hinted that 14.40 could have some non meraki vpn instability issues in the firmware.

Thank you for this post.  Meraki support has never been much help with Non-Meraki S2S VPN.  The issues were so obviously on their side too.  Well documented issues littering the forums online with multiple peer brands but they take the easy way out and try blaming the peer anyway.  I upgraded our MX to the 15.37 firmware and the issues have completely gone away.  I can see on our Sophos UTM 9 that it no longer thinks the MX is behind a NAT.

Interesting because i got the idea to do this from meraki support.

 

they said the way vpn is handled within the firmware is completely different from MX15.xx

 

but nice to see it also solved your problem.

I have this exact same configuration and issues you are describing.  Our Sophos UTM 9 in our datacenter thinks our MX's are NAT-T when they are not.  We experience the same unstable S2S IPSEC VPN issues you describe.  We have no problems with our remote sites on Cradlepoint, Just the Meraki sites.   I'm wondering if there is a way to turn off NAT-T on the Sophos and manually NAT through the MG21.  I have not found a solution yet.  Please update the post if you do.

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.