Translating classic ACLs to site-to-site VPN firewall rules

[iores]

Hi,

I need to translate hundreds of individual ACLs to one "big ACL" comprised of site-to-site VPN firewall rules.

Since the site-to-site VPN firewall rules are applied to the whole organization, it is not just copy-and-paste.

What are you experiences or suggestions to effectively perform this?

[alemabrahao]

You can use APIs.

https://developer.cisco.com/meraki/api-v1/update-organization-appliance-vpn-vpn-firewall-rules/

[iores]

I was aiming more at how to create one big central ACL from hundreds of single ACLs, without the need to analyze every ACL entry. For example, if one ACL entry at location X, uses summarized prefix (10.0.0.0/8) to denote source IPs at that specific location, if I just copy this as site-to-site VPN firewall rule I could influence traffic from all locations, not just X, and I don't want to do that. 

[alemabrahao]

I believe there's no magic/easy solution.

You have to analyze each ACL you create to know which sources, destinations, and ports to allow or deny.

How can you do this without even knowing the current configuration?

[iores]

Well, in such Meraki setup where one big central "ACL" is used for VPN traffic, I have no other option but tu analyze each ACL entry. 

[ww]

Maybe you could use group policies and attach it to a vlan. Group policy fw rules are stateless like acl's.

[iores]

Group policy attached to a VLAN will work for site-to-site VPN traffic?

[alemabrahao]

For S2S VPN ACLs, no.

Group policy ACLs are for LAN L3 rules.

[iores]

I have tried basic group policy to deny ICMP traffic from site A to site B. Group policy was applied to source VLAN at site A, and it actually denied ICMP traffic. What am I missing? 

[alemabrahao]

That's correct, that Group Policy was applied to the LAN and not the VPN. Since you blocked ICMP on the LAN for a specific source and destination, it's being blocked, but not by the S2S VPN rules, but rather by layer 3 rules.

Take a look at this document.

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

[iores]

How exactly S2S rules work? On which device exactly are they being applied? Where is the point of enforcement since they are applied at organization level? 

[alemabrahao]

As mentioned by GIdenJoe, you need to consider site-to-site traffic as a separate ZONE.

Generally, site-to-site VPN rules are applied organization-wide, across all VPN-enabled MX devices.

VPN Firewall Rule Considerations

When configuring VPN firewall rules, it's important to remember that traffic should be blocked as close as possible to the originating client device. This reduces traffic in the VPN tunnel and results in better network performance. Therefore, site-to-site firewall rules are only applied to outbound traffic. Thus, the MX cannot block VPN traffic initiated by IPsec VPN peers.

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

Note - Site-to-Site Firewall Rules Behavior when Group Policy is Configured

• If Site to Site Outbound Firewall Rule allows and Group Policy L3 denies, traffic will be denied.

• If Site to Site Outbound Firewall Rule denies and Group Policy L3 allows, traffic will be denied.

• If Site to Site Outbound Firewall Rule denies and Group Policy whitelisted preset is configured, traffic will be denied.

[GIdenJoe]

You have to consider the site 2 site traffic as being another ZONE.
So the regular L3 firewall including overriding group policies will not apply to site-to-site traffic.

You have to define those separately on the site-to-site vpn page.

Advantage is that they are org-wide so you can really structure them from spokes to hub and have single rules containing many sources.

[PhilipDAth]

It's a horrible job.

What I have done previously is to use the "Rule description" field to tag where the rule was migrated from.  For example:

fwcorp-inside-to-brancha-cameras

You can also search on these, which reduces the huge monolith of rules down to just the narrow set you are interested in.

[iores]

Yes, it really is horrible job. I will end up with one final ACL containing several thousand entries. I appreciate the suggestion about using description. 

[iores]

Is there any maximum number of such firewall rules, and do they affect performance of MXs?

[alemabrahao]

There is no hard published limit by Meraki, but performance and manageability can degrade with a large number of rules.
In practice, hundreds of rules can be configured, but Meraki recommends keeping the rule set as lean as possible for optimal performance and easier troubleshooting.

Not to mention that I've personally experienced a few cases where, when working with templates, the settings took a long time to be replicated to the MX records within the template.

[GIdenJoe]

Since you are talking about different ACL's you are probably talking about another platform type.
Which means the problem is getting the logic out of the original platform.

The site to site VPN rules are best used when you have centrally located resources that many branches must be able to reach.  In that case you must be able to identify those central resources and ports they are listening on through your existing ACL's from each location.

Then you need to make rules where the destination are those central resources but the source is a group object containing all the sources that make use of that service.  I usually make one rule per source VLAN type (example printers).
And at the end of each source vlan group end with a deny RFC1918 group rule so you deny them access to any other private subnet anywhere in the org.