MX as one-armed VPN Concentrator limitations

[M4TT]

Hi,

I was wondering if anyone has come across any limitations of using an MX as a one-armed VPN concentrator? I am looking at scenarios where we may have many remote workers (with the teleworker gateways) using AutoVPN. While this is all pretty standard if the MX is the HQ gateway and firewall I have some customers who are quite set on other third party firewalls that they have in place, in this case I believe the one-armed concentrator would be the way to go (although I guess a second gateway with the MX in NAT mode, but this may break certain security policies). Has anyone any stories of where this has shown to be problematic or to have limitations that effect the service? Even better if you've managed to over-come the issues.

Any issues with certain third party firewalls with traffic being blocked, or maybe with routing issues (many devices may not support OSPF)?

Sorry for the very open-ended question, but it's all very well reading the deployment guide which tells you how things 'should' work, I'm left wondering if real life is going to be so easy.

Thanks in advance

[GIdenJoe]

I think that design can have merit if you put the concentrator on it's own subnet hanging off the core switch.

If you can use an aggregate block for all your remote workers then you can use a single static route in the main network to reach all the teleworker subnets.

Using OSPF won't fully work because the LSA's will only go one way.

BGP is a possible consideration if the infrastructure supports it.

[PhilipDAth]

My preferred method is to keep the MX in NAT mode, and plug it into the Internet beside the existing firewall.  I usually plug WAN1 into the primary Internet circuit, and then get the customer to get a cheap domestic fibre and plug it into WAN2.  It's cheap insurance for a primary circuit failure.

If I can't plug WAN1 in directly to the Internet then I try to get a stub interface created between the existing firewall and the MX, and WAN1 goes there.  Then I can still use NAT mode, two WAN ports and SD-WAN.

In each case, the inside of the MX goes to the inside of the network.

If I can't do any of that then in desperation I use the MX in VPN concentrator mode.

I also allocate a prefix (a supernet) for all the remote subnets and use static routing.  The existing firewall default gateway should only need this single route then.  I avoid dynamic routing if possible.  It adds complexity that can often be avoided by design.

You sub-allocate your remote sites out of the supernet prefix.

If you have to run the MX through another firewall then I use a manual NAT forward for AutoVPN.

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

This works the most reliably and is the fastest of the AutoVPN rebuild options if there is a failure.

[GreenMan]

Remember that you might need to configure (or be better off with) a  Manual: Port forwarding   NAT traversal setup.   Basically this will tie your MX to a specific public IP and port, with appropriate matching config on your perimeter firewall.

https://documentation.meraki.com/MX/Site-to-site_VPN/Site-to-site_VPN_Settings#NAT_Traversal

Some of the related scenarios around this - and some interesting reading anyway - in here:   https://documentation.meraki.com/MX/Site-to-site_VPN/Troubleshooting_VPN_Registration_for_Meraki_Aut...

Remember too - don't hook up a VPNC MX directly to the raw Internet:   https://documentation.meraki.com/MX/Deployment_Guides/VPN_Concentrator_Deployment_Guide#Public_IP_as...

Bear in mind too - VPNC is the recommended mode for an MX in a DC, which is there to terminate tunnels from many remote peers (the clue's in the name).   For this reason many features of most use in a DC come to VPNC mode first - or sometimes exclusively.   One instance of that is the eBGP route exchange between AutoVPN and the DC environment, mentioned in another reply.

[cmr]

@M4TT we have our DC MXs set up as @GIdenJoe said.  They have been completely trouble free for a year or so with 8 remote sites over dual connected SD-WAN and an increasing number of homeworkers with either small MXs or Z3s using the supernet method described.

We use Sophos XGs as the main internet facing firewalls and their NAT plays nicely, I believe Palo Alto does not, not sure about other vendors.