ACL's for L2L VPN

Guys,

I came across a weird problem last week.

My ACL's for the match statements on the L2L VPN's have always contained the 'any' keyword in the source section.

eg. access-list VPN permit ip any 192.168.0.0 255.255.255.0

This has always worked in the past. I have recently deployed an ASA. I could see the VPN from the remote site (PIX 501, OS 6.5(3)) coming up, but the return tunnel from the ASA to the PIX wouldn't come up. It wasn't until I remove the any statement and specified the source network that the tunnel came up.

Is this by design, or is this supposed to work with any as the source address?

Thanks,

Chris.
LVL 16
InteraXAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

batry_boyCommented:
I've never seen it explicitly written out in the documentation, but I've always seen flaky behavior when using "any" as either the source or destination in a crypto ACL.  I've been told numerous times by the Cisco TAC that crypto ACL's need to be mirror images of each other on either side of a VPN tunnel (source-destination wise).  I only have anecdotal evidence that this is the case, but it's probably good practice to be specific on crypto ACL's anyway.
0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
InteraXAuthor Commented:
That matches my experiences.

Can you also answer the following.

I'm looking at using object groups to simplify my ACLs. I want to create one object group and deploy it to all my remote PIX's for use as the destination in the ACL.

eg. access-list VPN permit ip  192.168.0.0 255.255.255.0 object-group ALL_SITES

The object group ALL_Sites will contain the local network. Will this cause issues with the match statement?
0
batry_boyCommented:
No that should be fine since using an object group really just expands to the individual objects when you display the ACL.  For example, if your object group contained networks 192.168.1.0/24 and 192.168.2.0/24, then an ACL that looks like this in the "show run" output:

access-list VPN permit ip  192.168.0.0 255.255.255.0 object-group ALL_SITES

If you issued the command "show access-list VPN", it would expand out the individual entries from the object group and show you:

access-list VPN permit ip 192.168.0.0 255.255.255.0 192.168.1.0 255.255.255.0
access-list VPN permit ip 192.168.0.0 255.255.255.0 192.168.2.0 255.255.255.0

0
Turn Raw Data into a Real Career

There’s a growing demand for qualified analysts who can make sense of Big Data. With an MS in Data Analytics, you can become the data mining, management, mapping, and munging expert that today’s leading corporations desperately need.

InteraXAuthor Commented:
What happens though if you end up with one of the lines reading as follows.

access-list VPN permit ip 192.168.0.0 255.255.255.0 192.168.0.0 255.255.255.0

ie. both source and destination networks are the same.
0
batry_boyCommented:
Yeah, if you're object group contains source networks and you're applying the object group as a destination, this will definitely cause erratic behavior.  If you use object groups make sure you construct them such that this doesn't happen.  You may not be able to deploy a "global" object group on all your PIX'es that are the same everywhere...you may wind up having to customize them for each site...actually, you probably will have to.
0
InteraXAuthor Commented:
Ok,

So the 'rules' are basically, don't use the 'any' keyword and ensure that you don't have any ACE's where the source and destination network are the same.

Thanks.
0
InteraXAuthor Commented:
What if I have a deny ACE at the start of the ACL that denys traffic with the same source and destination networks?
0
batry_boyCommented:
I don't see any reason to put such an ACE in a crypto ACL.  If you don't want some specific traffic to be encrypted and subsequently sent down the tunnel, then just don't include it in the ACL at all.
0
InteraXAuthor Commented:
I'm thinking that you would have the object group with the same source and destination networks allowed, but explicitly blocked before the object groups.
0
batry_boyCommented:
If you want to reuse the same object group definition I suppose that is a way you could do that, but you would then have to create custom deny statements on each PIX to block the traffic you don't want encrypted.  It seems to me that it would just be easier to create custom crypto ACL's with only permit statements on each side of the tunnel.  This is the customary way of doing this...
0
InteraXAuthor Commented:
Thanks.
0
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Cisco

From novice to tech pro — start learning today.