Nested groups PIX.

Discussion in 'Cisco' started by AM, Jan 31, 2006.

  1. AM

    AM Guest

    hi all,

    PDM seems not to support nested groups (even if it displays them correctly).
    That was the question I posted on December the 6th and which Roberson replies to (I fad to specify nested not groups of
    groups)
    Ok the PDM doesn't manage nested group, does ADSM do it? May I use ADSM with PIX 6.3.(4)?
    Has anyone used them? Does they work properly? How many levels can I create? May a create unbalanced groups (mixed
    network-objects and groups of network-objects or groups with different levels of nesting)?
    I would use them for the VPNs.


    Alex.
     
    AM, Jan 31, 2006
    #1
    1. Advertising

  2. In article <K1ODf.71560$>, AM <> wrote:
    >Ok the PDM doesn't manage nested group, does ADSM do it?


    I haven't tried ADSM.

    >May I use ADSM with PIX 6.3.(4)?


    No.

    >Has anyone used them?


    I have used them from the CLI in PIX 6.x

    >Does they work properly?


    No problem.

    >How many levels can I create?


    I'd have to go back and check to be sure, but I think I've done
    at least 6 levels.

    >May a create unbalanced groups (mixed
    >network-objects and groups of network-objects or groups with different
    >levels of nesting)?


    Yes, no problem.

    >I would use them for the VPNs.


    Using object groups with VPNs can lead to problems. I do not mean
    inherent problems, just that you have to know exactly how they
    work, as otherwise you may run into one of those hair-pulling
    situations.


    When you have more than one object-group in an ACL entry, the
    right-most group is expanded first, then the second from the right and
    so on with the left-most group expanded the slowest. For example,

    object-group network off1hosts
    network-object host L1
    network-object host L2
    object-group network HQ
    network-object host HQ1
    network-object host HQ2
    access-list vHQ permit ip object-group off1hosts object-group HQ

    This will expand to

    access-list vHQ permit ip host L1 host HQ1
    access-list vHQ permit ip host L1 host HQ2
    access-list vHQ permit ip host L2 host HQ1
    access-list vHQ permit ip host L2 host HQ2


    On the other side of the VPN, you want the crypto map to be the
    "mirror image", so you would be tempted to create the same
    object groups and write,

    access-list voff1 permit ip object-group HQ object-group off1hosts

    But expand this out using the same right-first rule:

    access-list voff1 permit ip host HQ1 host L1
    access-list voff1 permit ip host HQ1 host L2
    access-list voff1 permit ip host HQ2 host L1
    access-list voff1 permit ip host HQ2 host L2

    Notice that the expanded order is not the same as for the other side:
    the middle two items switch places.

    Crypto ACLs are (like all other ACLs) checked from the top down,
    and the first clause that matches is used.

    If you avoided duplicates and if all of the entries are "host" entries
    with no subnet entries, then the difference in order between the two
    expanded lists will not matter.

    But if you have overlaps, perhaps because you are using groupings that
    *logically* do not necessarily overlap, then it is possible to end
    up in situations in which the change in order is important.

    The situation requires that there be a subnet specification
    and also a host (or subnet) that is part of the subnet. When
    the ACL is expanded on one side, the specific instance might
    appear in the expansion first, but on the other side, the subnet
    might appear in the expansion first. When the more specific
    host(s) are talking then on one side the SA used will be the
    specific one, but on the other side the SA that will be used will
    be the one generated with respect to the subnet. When a reply
    does not come back with the same SA as was used for the
    outgoing message, then the reply will not be decoded properly.

    These kinds of mismatches are very difficult to track down:
    you will stare and stare at the crypto maps and *know* that
    they are "obviously" mirrors of each other... but they aren't
    really because of the difference in expansion orders when the
    object positions are flipped around.
     
    Walter Roberson, Feb 1, 2006
    #2
    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. R Siffredi

    IPSEC/GRE VPN nested

    R Siffredi, May 12, 2004, in forum: Cisco
    Replies:
    0
    Views:
    601
    R Siffredi
    May 12, 2004
  2. Steve
    Replies:
    1
    Views:
    3,504
    Steve
    Nov 30, 2005
  3. AM
    Replies:
    2
    Views:
    462
  4. AM
    Replies:
    0
    Views:
    362
  5. AM
    Replies:
    1
    Views:
    1,156
Loading...

Share This Page