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.
I'd have to go back and check to be sure, but I think I've done at least 6 levels.
Yes, no problem.
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,
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.
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.