MX 450 SNAT Limitations

Lorenzo1
Here to help

MX 450 SNAT Limitations

Hello,

 

I have a significant number of users behind an on-premise MX 450 that use the Microsoft Native VPN Client to provide an 'always on' VPN connection into MS Azure.

 

I note that within the Meraki documentation that the native Meraki Client has a maximum of 500 users.

 

My assumption (right/wrong) is that the both Meraki and MS VPN Clients will function similarly, therefore is that 500 limit applicable to native MS clients?

 

My thinking is that maybe port exhaustion is being incurred as early arrivers at the office have no VPN issues, where as those arriving late struggle to get a connection.

 

Any thoughts appreciated.

 

9 Replies 9
alemabrahao
Kind of a big deal
Kind of a big deal

The Meraki Client VPN (using L2TP/IPsec) has a recommended limit of 500 concurrent users.
This 500-user limit is specific to Meraki's native client VPN implementation, not necessarily for third-party VPN clients like the Microsoft Native VPN Client.

This doesn't mean it won't accept more connections; it's simply a number that ensures the MX hardware won't work beyond its designed capacity.

I am not a Cisco Meraki employee. My suggestions are based on documentation of Meraki best practices and day-to-day experience.

Please, if this post was useful, leave your kudos and mark it as solved.
Lorenzo1
Here to help

I was clinging by a thread to the slightest possibility that there might be some commonality between Meraki Client VPN (using L2TP/IPsec) and the native Microsoft Client which uses IPsec or SSTP. But sounds as if there none.😕

 

In my mind I was trying to explain why I don't have the issue at an identical site but with lower occupancy. That's 500+ compared with sub 500. No other reported performance issues and Microsoft have confirmed no issues on the terminating VPN side.

 

PhilipDAth
Kind of a big deal
Kind of a big deal

>My thinking is that maybe port exhaustion

 

You've missed a step by describing potential reasons for the problem, but not the problem itself.  🙂

What is going wrong?

 

cmr
Kind of a big deal
Kind of a big deal

"early arrivers at the office have no VPN issues, where as those arriving late struggle to get a connection"

 

Have you monitored the load on the MX, if you look at just the summary report for just the appliance network you will see a 24hr load graph.

If my answer solves your problem please click Accept as Solution so others can benefit from it.
PhilipDAth
Kind of a big deal
Kind of a big deal

Do you think the poster means those arriving late to the office (and I assume these people don't require a VPN connection since they are in the office) are having issues browsing the web, or something else?

cmr
Kind of a big deal
Kind of a big deal

I think that when in the office they need a VPN to some sort of cloud resource.  I'm actually assisting a company that has a similar setup where every device needs a client VPN active to work with most of their applications, it is also causing some problems, but does actually provide very granular security...

If my answer solves your problem please click Accept as Solution so others can benefit from it.
Lorenzo1
Here to help

Good point I'll take a look and report back.

Lorenzo1
Here to help

The problem relates to failure to establish a VPN connection to Azure for Enterprise services such as AD. Whether the user is on-prem or not (at home), a tunnel is established and is 'always on'.

Microsoft have investigated their terminating infrastructure and report no utilisation issues.

We have no reported issues with browsing, email, Teams apps and plenty of bandwidth at the office egress.

Therefore, I'm looking for pinch points that appear to relate to the number of end users behind an MX. We don't have the same issue at an identical office with a lower occupancy.

 

 

 

PhilipDAth
Kind of a big deal
Kind of a big deal

Is this using Microsoft's L2TP over IPSec?  If so, try adding these registry keys to a test machine:

New-ItemProperty -Path HKLM:\SYSTEM\CurrentControlSet\Services\PolicyAgent -Name AssumeUDPEncapsulationContextOnSendRule -Value 2 -PropertyType DWORD -Force

 It makes the Microsoft client work much better when sitting behind NAT.

Get notified when there are additional replies to this discussion.