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

iores
Getting noticed

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

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?

8 Replies 8
alemabrahao
Kind of a big deal
Kind of a big deal

You can use APIs.

 

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

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.
iores
Getting noticed

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
Kind of a big deal
Kind of a big deal

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?

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.
iores
Getting noticed

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
Kind of a big deal
Kind of a big deal

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

PhilipDAth
Kind of a big deal
Kind of a big deal

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
Getting noticed

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. 

GIdenJoe
Kind of a big deal
Kind of a big deal

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.

Get notified when there are additional replies to this discussion.