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

Discussion in 'Cisco' started by Scott Townsend, Jun 7, 2006.

  1. 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 <ACL-Name> extended permit ip <Subnet_1> <Subnet_2>

    access-list <ACL-Name> extended permit ip <Subnet_1> <Subnet_3>

    access-list <ACL-Name> extended permit ip <Subnet_1> <Subnet_...>

    access-list <ACL-Name> extended permit ip <Subnet_1> <Subnet_11>

    access-list <ACL-Name> extended permit ip <Subnet_2> <Subnet_1>

    access-list <ACL-Name> extended permit ip <Subnet_2> <Subnet_3>

    access-list <ACL-Name> extended permit ip <Subnet_2> <Subnet_...>

    access-list <ACL-Name> extended permit ip <Subnet_2> <Subnet_11>

    access-list <ACL-Name> extended permit ip <Subnet_...> <Subnet_...>
    access-list <ACL-Name> extended permit ip <Subnet_11> <Subnet_1>

    access-list <ACL-Name> extended permit ip <Subnet_11> <Subnet_2>

    access-list <ACL-Name> extended permit ip <Subnet_11> <Subnet_...>

    access-list <ACL-Name> extended permit ip <Subnet_11> <Subnet_10>

    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<-
    Scott Townsend, Jun 7, 2006
    #1
    1. Advertising

  2. In article <MxBhg.40809$>,
    Scott Townsend <scott-i@.-N0-SPAMplease.enm.com> wrote:
    >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


    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.


    >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 <ACL-Name> extended permit ip <Subnet_1> <Subnet_2>
    >access-list <ACL-Name> extended permit ip <Subnet_1> <Subnet_3>
    >access-list <ACL-Name> extended permit ip <Subnet_1> <Subnet_...>
    >access-list <ACL-Name> extended permit ip <Subnet_1> <Subnet_11>
    >access-list <ACL-Name> extended permit ip <Subnet_2> <Subnet_1>
    >access-list <ACL-Name> extended permit ip <Subnet_2> <Subnet_3>

    [...]

    >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?


    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.


    >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?


    If you use object-groups, your ACLs reduce to one line each.
    Walter Roberson, Jun 7, 2006
    #2
    1. Advertising

  3. 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<-

    "Walter Roberson" <> wrote in message
    news:c0Ehg.254175$P01.60386@pd7tw3no...
    > In article <MxBhg.40809$>,
    > Scott Townsend <scott-i@.-N0-SPAMplease.enm.com> wrote:
    >>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

    >
    > 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.
    >
    >
    >>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 <ACL-Name> extended permit ip <Subnet_1> <Subnet_2>
    >>access-list <ACL-Name> extended permit ip <Subnet_1> <Subnet_3>
    >>access-list <ACL-Name> extended permit ip <Subnet_1> <Subnet_...>
    >>access-list <ACL-Name> extended permit ip <Subnet_1> <Subnet_11>
    >>access-list <ACL-Name> extended permit ip <Subnet_2> <Subnet_1>
    >>access-list <ACL-Name> extended permit ip <Subnet_2> <Subnet_3>

    > [...]
    >
    >>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?

    >
    > 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.
    >
    >
    >>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?

    >
    > If you use object-groups, your ACLs reduce to one line each.
    Scott Townsend, Jun 7, 2006
    #3
  4. 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 <ACL-Name> extended permit ip NETWORK-Kit-n-Kaboodle-ALL
    NETWORK-Kit-n-Kaboodle-ALL


    Thanks!



    "Walter Roberson" <> wrote in message
    news:c0Ehg.254175$P01.60386@pd7tw3no...
    > In article <MxBhg.40809$>,
    > Scott Townsend <scott-i@.-N0-SPAMplease.enm.com> wrote:
    >>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

    >
    > 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.
    >
    >
    >>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 <ACL-Name> extended permit ip <Subnet_1> <Subnet_2>
    >>access-list <ACL-Name> extended permit ip <Subnet_1> <Subnet_3>
    >>access-list <ACL-Name> extended permit ip <Subnet_1> <Subnet_...>
    >>access-list <ACL-Name> extended permit ip <Subnet_1> <Subnet_11>
    >>access-list <ACL-Name> extended permit ip <Subnet_2> <Subnet_1>
    >>access-list <ACL-Name> extended permit ip <Subnet_2> <Subnet_3>

    > [...]
    >
    >>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?

    >
    > 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.
    >
    >
    >>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?

    >
    > If you use object-groups, your ACLs reduce to one line each.
    Scott Townsend, Jun 7, 2006
    #4
  5. In article <2lEhg.133349$>,
    Scott Townsend <scott-i@.-N0-SPAMplease.enm.com> wrote:
    >So I have the Following setup:


    >object-group network NETWORK-HBG-ALL

    [...]
    >object-group network NETWORK-SF-ALL

    [...]

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


    >object-group network NETWORK-Kit-n-Kaboodle-ALL

    [listing all the contents]

    >and just have ACLs defined as:
    >access-list <ACL-Name> extended permit ip NETWORK-Kit-n-Kaboodle-ALL 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
    Walter Roberson, Jun 7, 2006
    #5
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Dan Rice
    Replies:
    9
    Views:
    906
    Dan Rice
    Feb 4, 2005
  2. AM
    Replies:
    0
    Views:
    6,783
  3. xhon
    Replies:
    0
    Views:
    774
  4. mvalpreda
    Replies:
    1
    Views:
    643
    allan16
    Sep 7, 2007
  5. Jack
    Replies:
    0
    Views:
    652
Loading...

Share This Page