MX67W blocking country IP blocks when a 1:1 NAT is involved

[alceryes1]

I learned that any 1:1 (or 1:M) NATting supersedes Layer 7 country blocking. See here - https://community.meraki.com/t5/Security-SD-WAN/MX67W-does-1-1-NAT-forwarding-superceed-layer-7-coun...

Is there any way to use a country's IP block to actually block countries from accessing internat IPs for systems/services on a 1:1 NAT?

TIA!

[alemabrahao]

Unfortunately, not directly using Meraki's built-in L7 firewall. You can try manually blocking IP ranges associated with specific countries using L3 firewall rules or put a reverse proxy or web application firewall in front of your NAT service.

[alceryes1]

If I create a layer 3 to/from deny rule (not sure of the limit of IP entries) will that supersede the 1:1 NAT rule and deny any to/from traffic for those specific IPs?

[alemabrahao]

I won't confirm it, so I left it as a suggestion for testing.

https://documentation.meraki.com/General_Administration/Cross-Platform_Content/Layer_3_and_7_Firewal...

[alceryes1]

I had some time, so I put in a support ticket.

Will post my findings.

[MartinLL · Accepted solution]

The only way i know of to enforce firewall settings on a 1:1 or other inbound nat forms is to enable Nat Exemption in the early access page. This enforces inbound firewall rules for inbound traffic to a NAT IP. Not sure how it interacts with L7 geoblock tho. You will need to test that.

https://documentation.meraki.com/MX/Networks_and_Routing/NAT_Exceptions-No_NAT_on_MX_Security_Applia... 

[alceryes1]

I believe this is different from what I need. I don't need the internal IP preserved, I just need some mechanic/rule to be able to block countries from external services on particular ports (NATted services).

I'm surprised this hasn't come up previously. Meraki users should be able to block IP list or whole country access to NATted services like Exchange Webmail or Microsoft RDWeb services(?)

[MartinLL]

If you read the article again you can see that when you enable this feature you get the option of using inbound firewall rules which change the default behaviour of the implicit allow rule created when you add a inbound nat rule.

With this feature enabled you can still NAT. I just suggested trying to enable this for the inbound firewall function.

And yes i agree. I would also like for L7 geoblock rules to apply to inbound nat by default.

[alceryes1]

Maybe I'm reading it wrong, but it appears that, in order to override the NAT exception, I need to disable NAT on a particular uplink or VLAN, but I still want the NAT to be in place. Exposing an internal IP to the internet (in my simple set up) isn't possible.

In any case, we'll see what support comes back with and I'll post my findings here.

[MartinLL]

You are reading it wrong. When you opt in for this feature you just enable the option to do no-nat on uplinks. Unless you enable the no-nat check boxes you still NAT.

The only immediate thing that changes when you opt in for this feature is the inbound firewall rules.

Try it on a test network

[TyShawn]

Just a little note I opened up multiple tickets, have multiple sales calls, and countless make a wish requests for this feature. This lack of function is what forced my day job to move away from the MX line at our HQ. 

[alceryes1]

Meraki has confirmed that this is the current solution.

However, this is just a band aid for layer 7 country blocking. Imagine having to enter every CIDR notation for all the blocks of IPs for the 20 or so countries that the US government considers unfriendly. This is unacceptable, IMHO.

[MartinLL]

Good to know. Did they confirm that L7 rules does not work when you do it this way? If enabling inbound FW makes this traffic follow the regular rule processing flow it should in theory work.

For example if you allow any inbound towards the NAT IP and you add L7 geoblock rules for the countries you want to allow.

If you want to test it you can DM me and i will attempt to connect from where i live.

[alceryes1]

I have asked them for clarification as they weren't clear.

Having to enter in hundreds of CIDR blocks in a layer 3 rule would probably slow down peak performance (and take hours to do). It's not a good option.

[MartinLL]

Yeah i get that. But you should not need to add anything other then allow any inbound toward the NAT IP in L3 firewall rules. Once it matches and is allowed it should continue to the L7 rule processing where you do geoblock assuming you have the advanced security license.

https://documentation.meraki.com/General_Administration/Cross-Platform_Content/Layer_3_and_7_Firewal... 

[alceryes1]

Correct. The question is whether enabling this NAT exception changes the way layer 7 is processed. Without NAT exeption, 1:1 and 1:M NATs actually create a hidden implicit rule that supercedes Layer 3 and 7. That functionality would need to change.

I'll post what Meraki replies with. Thanks again.

[alceryes1]

Meraki support replied with unfortunate news. 1:1 and 1:M NATs will still bypass any Layer 7 country blocking, even with the early access NAT exceptions function active. So, for country blocks, all the hundreds of CIDR entries would need to be added as a layer 3 inbound rule and the NAT exceptions activated.

The other option mentiond by Meraki is to scope out the 1:1 NAT allow list by using the country IP blocks that are allowed (instead of using any). That way you don't have to use an early access feature. I am unsure how having hundreds of CIDR blocks in the 1:1 NAT will affect performance though.

Thanks for everyone's help.