Crypto Maps with Overlapping ACL's

[routerdork]

What do you guys do when you run into overlapping ACL's on crypto maps? We are getting big enough that our customer IP's are starting to overlap. I was thinking we could do a source NAT so that each crypto map ACL is unique. Seems to me like there should be a better way but I don't know what it would be.

[Reggle]

With the multiple companies I've worked for here, it usually ends up with a lot of NAT over the VPN tunnel. Try to allocate specific ranges for it, it helps a bit.

[GeorgeS]

We do also NAT but you do not want to do them on the same FW as you do your vpn. Maybe now is the best solution and everything to do the NAT and vpn on the same FW, but eventually it will cause chaos. 
Not sure for how big network we speak and how scalable is, but in my opinion have a different FW for NAT and different for VPN. If we speak for a s2s vpn between 2 different companies this would be pretty difficult, as if they do not have a second fw for that reason they will not buy one!

Personally in all the new sites i am building iam trying to push and usually with success the 2 FW rules, 1 for VPN, 1 for ACL/NAT. No matter how good you are with VPN building/tshoot them, after one point it will become mess, and eventually, it will not be you all the time the one who does changes and tshoot issues, someone else will take it after you...
Having one fw for acl/nat/vpn will just cause chaos. IF they do not want to invest on buying a new pair of FW just for that, push the context option. win win.

[dlots]

What I did when I had lots of over-lapping IPs is I brought everyone into my system on their own VRF, then I had a box that just did NAT between the VRFs, and global.

Don't know i fthat works for your setup though.

[icecream-guy]

MPLS running MP-BGP comes to mind but I could be barking up the wrong tree,

anywhoo, in your customers best interest, for security sake, you should segregate each customers data from each others customers data, create shared VRF's and import data for those customers that want to share services.

[routerdork]

The customers are already segregated by IP so each ACL is unique as they each have their own app server. The server we monitor with is what causes the issue because it always uses the same outbound IP for ICMP. We have a /15 set aside for NAT so that each customer gets a /24 or larger depending on their user base. So we are thinking we'll take the last /23 in the /15 and use that for the unique IP's for each customer. All of this NAT will hopefully be temporary as we are testing out application delivery using F5.

I would much prefer Ristau's comment with an MPLS circuit for each but unfortunately that's a cost neither us nor our customers want to pay. I also did the math and if each customer had to put in a 1RU box for an MPLS circuit we'd fill up 8 racks from one ASA pair's tunnels. Ideally MPLS would fix a lot of issues but just not an option today.

VRF's are a great idea too but would also require new equipment purchases that likely won't happen. Our customer base is fairly large for a small company but our network footprint is little. Should we still require all these VPN's in the long run it's not a bad solution to work towards.

I have heard the idea of using 2 firewalls before and I just don't like it. I understand how it can make things easier but I can also see it making things harder when managing rules on 2 boxes. My opinion is that one box should be able to handle the whole piece of the VPN.

Thanks for all the responses. I think we'll just do a source NAT for each one for now until we are ready for F5 to takeover. It's the least amount of changes and cost for a hopefully short term fix.

[GeorgeS]

actually the 2 fw is a lot simplier thatn what u think, as you will have your ACL before the vpn and the VPN fw will be a vpn concetrator style where u just create the tunnel and nothing else, so you actually maintain one set of rules.  But here your case is a bit different than the one  iam describing and i do not think is the best idea to what u want to achieve, vrf are.
Let us know how the f5 will go if you buy it, is becoming very popular.

[wintermute000]

Fvrf and each customer on its own internal vrf. Aggregate/nat/intervrf on a separate layer 3 firewall.