Question about ACLs for Crypto map

[lostngone]

In the examples I have found on setting up L2L IPSec connections when they create the traffic matching ACL for the crypto map they show a single subnet to single subnet ACL and just flip the source and destination for the other side.

For example:

Router A: access-list 100 extended permit ip 1.1.1.0 255.255.255.0 1.1.2.0 255.255.255.0

Router B: access-list 100 extended permit ip 1.1.2.0 255.255.255.0 1.1.1.0 255.255.255.0

___

Here is a crude diagram of what I have.

In my situation I have many subnet's on one side and a single on the other side. At the remote site I do not do NAT or split tunnel, all traffic is routed down the tunnel. In my case can I simply use "any" when building my ACLs?

For example:

ASA: access-list to_cryptomap extended permit ip any 192.168.100.0 255.255.255.0

Remote router: access-list 100 permit ip 192.168.100.0 0.0.0.255 any

Will this work and what isses or problems am I going to have if I do this? Is there  a better way?

Message was edited by: Lee Hobart Spelling

[Jon Marshall]

Lee

Yes you can use "any" if you want. As long as the acl's match at both ends and are flipped as you say it will work.

No major issues, it simply means all subnets are permittted. If that is what you want then fine but sometimes you want to limit which subnets can go down the VPN tunnel.

Jon

[Vinayaka Raman]

As long as your ACL at one end is the mirrored on other end,(meaning the packet encrypted at one end should be decrypted at other end and vice versa) it should work..

[Richard Burts]

I would offer different advice than my colleagues have. There are several config guides about L2L IPSec that advise not using the permit ip any options. Here is an example of the warning:

Be careful not to use the word any in your ACL.

Here is the URL from which it came:

http://www.cisco.com/en/US/partner/tech/tk583/tk372/technologies_tech_note09186a0080094203.shtml#acl

I continued to look and found a better reference which does provide some of the reasons why it is recommended to not configure permit ip any. Here is the URL:

http://www.cisco.com/en/US/partner/docs/security/pix/pix50/configuration/guide/ipsec.html#wp7578

and here is one of the paragraphs which explain the reasons:

When you create crypto access lists, using the any keyword could cause problems. Cisco discourages the use of the any keyword to specify source or destination addresses.

The permit any any statement is strongly  discouraged, as this will cause all outbound traffic to be protected  (and all protected traffic sent to the peer specified in the  corresponding crypto map entry) and will require protection for all  inbound traffic. Then, all inbound packets that lack IPSec protection  will be silently dropped.

You need to be sure you define which packets to protect. If you must use the any keyword in a permit statement, you must preface that statement with a series of deny statements to filter out any traffic (that would otherwise fall within that permit statement) that you do not want to be protected.

HTH

Rick

[jimmyp1983]

I would discourage the use of the any keyword as well. You can't use object groups in crypto ACLs on routers.

https://supportforums.cisco.com/discussion/11110466/ios-15-vpn-site-site-acls-object-groups

http://www.cisco.com/c/en/us/td/docs/ios/sec_data_plane/configuration/guide/15_1/sec_data_plane_15_1_book/sec_object_group_acl.html#wp1132617

[IcebergTitanic]

I agree with Richard there about not using the permit any commands. Ideally, I think I would use object-groups on either end that define the local LAN, and the VPN'd LANs, then you would only need a single ACL line to get the appropriate traffic. Maybe something like:

permit ip object-group Local_LAN object-group VPN_Peer_LAN

(Note,  I usually work with ASA's so can't remember if the routers support object-groups in the same way...)

We ran into a problem with a NAT'd VPN recently, where the issue was that a permit ip any host xxx.xxx.xxx.xxx was used to try and grab all traffic aimed at the far and and throw it at the tunnel. The problem was that the ASA then grabbed the traffic *before* it hit the NAT process, and was trying to throw the un-NAT'd traffic at the tunnel. As a result the other end rejected it due to it not matching the expected tunneled network.