PIX ACLs for Inside/outside Nat and Crypto - All the same?

I was working with a Cisco Engineer getting some issues with a PIX to PIX VPN worked out and they recommended that my Access lists for allowing NATed traffic from inside to outside to inside all have entries for each subnet in both directions and they make a different ACL for each interface/connection, even though they are all the same. Not sure if it makes sense. .

So for example I have the Following references to ACLs:

nat (outside) 0 access-list outside_nat0_outbound nat (outside) 0 access-list outside_nat0_inbound outside nat (inside) 0 access-list inside_nat

crypto map outside_map 20 match address outside_cryptomap_20

So that makes the 4 ACL: outside_nat0_outbound outside_nat0_inbound inside_nat outside_cryptomap_20

I have 11 different Subnets that are connected one way or another to the PIXs, so the Cisco Tech recommended that for each of the Four lists I have the following:

access-list extended permit ip

access-list extended permit ip

access-list extended permit ip

access-list extended permit ip

access-list extended permit ip

access-list extended permit ip

access-list extended permit ip

access-list extended permit ip

access-list extended permit ip access-list extended permit ip

access-list extended permit ip

access-list extended permit ip

access-list extended permit ip

So that would make it 110 entries per ACL and 440 for the lot of them.

Since they are the same why should not use the same name? Does this seem right?

All Subnets are 10.X.0.0/16 Why not just put in a 10.0.0.0/8 to 10.0.0.0/8 and be done with it?

Thank you, Scott

Reply to
Scott Townsend
Loading thread data ...

You appear to be using PIX 7 (according to some of your other remarks.) I don't know about PIX 7, but in PIX 6 you may only use a single nat 0 access-list statement per interface.

[...]

I don't know about PIX 7, but in PIX 6, the contents of access-lists applied as access-groups are internally manipulated for the purposes of the Adaptive Security Algorithm. If you have that same ACL being used for a crypto map, then suddenly the Security Associations (SA's) implied by the crypto map have to change, which Does Bad Things.

There are also several known bugs in PIX 5 and PIX 6 that show that there must be other similar (but undocumented) linkages for some of the other features. The moral is "Never use the same access-list for two different purposes" -- in some cases it will *definitely* cause problems, and in other cases you may or may not encounter bugs or undocumented restrictions.

If you use object-groups, your ACLs reduce to one line each.

Reply to
Walter Roberson

Thank you for your reply.

Yes I am using 7.0(5)

Okay I can relate to not using the same list for different things...

object-groups? Guess I'll have to look into that. I have an Excel Spreadsheet that Creates all 440 lines for each of the ACLs just in case...

Thanks, Scott >>I was working with a Cisco Engineer getting some issues with a PIX to PIX

Reply to
Scott Townsend

So I have the Following setup:

object-group network NETWORK-HBG-ALL network-object 10.1.0.0 255.255.0.0 network-object 10.10.0.0 255.255.0.0 network-object 10.254.0.0 255.255.0.0 object-group network NETWORK-SF-ALL network-object 10.2.0.0 255.255.0.0 network-object 10.3.0.0 255.255.0.0 network-object 10.6.0.0 255.255.0.0 object-group network NETWORK-FITCH-ALL network-object 10.13.0.0 255.255.0.0 object-group network NETWORK-OLIVET-ALL network-object 10.11.0.0 255.255.0.0 object-group network NETWORK-235HBG-ALL network-object 10.12.0.0 255.255.0.0

Can the groups be really anything I want? so I could have:

object-group network NETWORK-Kit-n-Kaboodle-ALL network-object 10.1.0.0 255.255.0.0 network-object 10.10.0.0 255.255.0.0 network-object 10.254.0.0 255.255.0.0 network-object 10.2.0.0 255.255.0.0 network-object 10.3.0.0 255.255.0.0 network-object 10.6.0.0 255.255.0.0 network-object 10.13.0.0 255.255.0.0 network-object 10.11.0.0 255.255.0.0 network-object 10.12.0.0 255.255.0.0

and just have ACLs defined as: access-list extended permit ip NETWORK-Kit-n-Kaboodle-ALL NETWORK-Kit-n-Kaboodle-ALL

Thanks!

Reply to
Scott Townsend

[...]
[...]

[listing all the contents]

NETWORK-Kit-n-Kaboodle-ALL

Once you've created meaningful network groups, you will often find that you don't really want everything to everything. In such cases, it often turns out to be good to use the group-object clause within an object-group in order to "include" the various groups. For example,

object-group network local_office group-object NETWORK-235HBG-ALL

object-group network remote_offices group-object NETWORK-HBG-ALL group-object NETWORK-SF-ALL

access-list ACL-NAME extended permit ip object-group local_office object-group remote_offices

Reply to
Walter Roberson

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.