Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people, just like you, are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
Solved

ACL's for L2L VPN

Posted on 2007-03-19
11
667 Views
Last Modified: 2008-01-09
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.
0
Comment
Question by:InteraX
  • 6
  • 5
11 Comments
 
LVL 28

Accepted Solution

by:
batry_boy earned 125 total points
ID: 18747467
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
 
LVL 16

Author Comment

by:InteraX
ID: 18747756
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
 
LVL 28

Expert Comment

by:batry_boy
ID: 18748266
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
PRTG Network Monitor: Intuitive Network Monitoring

Network Monitoring is essential to ensure that computer systems and network devices are running. Use PRTG to monitor LANs, servers, websites, applications and devices, bandwidth, virtual environments, remote systems, IoT, and many more. PRTG is easy to set up & use.

 
LVL 16

Author Comment

by:InteraX
ID: 18748296
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
 
LVL 28

Expert Comment

by:batry_boy
ID: 18748333
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
 
LVL 16

Author Comment

by:InteraX
ID: 18748429
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
 
LVL 16

Author Comment

by:InteraX
ID: 18748445
What if I have a deny ACE at the start of the ACL that denys traffic with the same source and destination networks?
0
 
LVL 28

Expert Comment

by:batry_boy
ID: 18748935
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
 
LVL 16

Author Comment

by:InteraX
ID: 18749198
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
 
LVL 28

Expert Comment

by:batry_boy
ID: 18749515
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
 
LVL 16

Author Comment

by:InteraX
ID: 18754920
Thanks.
0

Featured Post

Free Tool: IP Lookup

Get more info about an IP address or domain name, such as organization, abuse contacts and geolocation.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

This article will cover setting up redundant ISPs for outbound connectivity on an ASA 5510 (although the same should work on the 5520s and up as well).  It’s important to note that this covers outbound connectivity only.  The ASA does not have built…
Use of TCL script on Cisco devices:  - create file and merge it with running configuration to apply configuration changes
As a trusted technology advisor to your customers you are likely getting the daily question of, ‘should I put this in the cloud?’ As customer demands for cloud services increases, companies will see a shift from traditional buying patterns to new…
Both in life and business – not all partnerships are created equal. Spend 30 short minutes with us to learn:   • Key questions to ask when considering a partnership to accelerate your business into the cloud • Pitfalls and mistakes other partners…

856 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question