Meraki MX - Hack to implement inbound firewall rules on Non-Meraki VPN Peers

Solved
StingeyNinja
Getting noticed

Meraki MX - Hack to implement inbound firewall rules on Non-Meraki VPN Peers

There are various threads already bemoaning the lack of inbound firewall rules for Non-Meraki VPN Peers (bump for Product Management to take a look at that please), but rather than just pile-on, I wanted to see if anyone had got this working by way of workaround.

 

Scenario:

We have an MX in the office that provides Client VPN (native and AnyConnect) connectivity to the office/server environment (while we all work from home), and we want to add a Non-Meraki VPN peer to allow all our internal systems to access a SaaS solution.  From a security perspective though, the traffic that could originate from this SaaS provider is a complete unknown and we don't want to to open our network up to takeover via a 3rd party, but without inbound VPN firewall rules this isn't possible with the MX.

 

The Workaround:

Could I install another MX in a different 'organization' behind the Office MX, let's call this the DMZ MX, and then configure the DMZ MX with 2 non-Meraki VPN peers, i.e.:

1: (Office MX) <-- (DMZ MX)

2:                          (DMZ MX) --> SaaS

 

This would allow the DMZ MX to specify what is allowed outbound to the Office MX. 

From the Office MX side I would configure a static route to the SaaS IP subnets via the DMZ MX IP address, allowing me to address the SaaS provider systems as if it was a direct VPN tunnel.  Presumably then traffic originating from the SaaS provider's network will be treated as 'outbound' then it egresses the DMZ MX in the direction of the Office MX, allowing firewall rules to be applied.

 

The main complication that I can see if that I I only have one internet connection and a single public IP, so I would need to create a VLAN on the Office MX and plug the DMZ MX into it for internet connectivity (and add firewall rules to prevent the DMZ MX from accessing the internal subnets).  Presumably I may then also need to open some ports inbound on the Office MX to allow IPsec tunneling to the DMZ MX.

 

Has anyone tried this? Did it work? Any gotchas?

1 Accepted Solution
KarstenI
Kind of a big deal
Kind of a big deal

I did this but not with an additional MX, I use an ASA or an FTD for this. But the concept is the same. Based on availability of addresses I use one of these two setups:

KarstenI_0-1708338883612.jpeg

 

If you found this post helpful, please give it Kudos. If my answer solves your problem, please click Accept as Solution so others can benefit from it.

View solution in original post

3 Replies 3
KarstenI
Kind of a big deal
Kind of a big deal

I did this but not with an additional MX, I use an ASA or an FTD for this. But the concept is the same. Based on availability of addresses I use one of these two setups:

KarstenI_0-1708338883612.jpeg

 

If you found this post helpful, please give it Kudos. If my answer solves your problem, please click Accept as Solution so others can benefit from it.
StingeyNinja
Getting noticed

Is there any reason this approach wouldn't work if I used an MX in place of the ASA/FTD in these diagrams?  Sometimes it's nice to stick with a single platform, single licence renewal, etc., and cloud-managed patching on the MX is always a plus.

KarstenI
Kind of a big deal
Kind of a big deal

Yes, it is also possible with the MX. Your mentioned benefits are real, but the drawbacks of the MX for extranet VPN are also often relevant.

You won't have a single license renewal if you place the MX in a different dashboard org. But the rest should be fine. 

If you found this post helpful, please give it Kudos. If my answer solves your problem, please click Accept as Solution so others can benefit from it.
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