:Thanks for your reply. Not sure if I'm more confussed.
Sorry, I have that effect on people sometimes ;-)
:I have delt with PIX 515 and 515E where the typical config looks similar to :the following; : access-list allowed_traffic permit ip 9.8.7.0 255.255.255.0 1.2.3.0
255.255.255.0 : access-list allowed_traffic permit ip 9.8.7.0 255.255.255.0 4.5.6.0
255.255.255.0 : access-list allowed_traffic permit ip 6.5.4.0 255.255.255.0 1.2.3.0
255.255.255.0 : access-list allowed_traffic permit ip 6.5.4.0 255.255.255.0 4.5.6.0
255.255.255.0 : crypto map crypto_map 10 match address allowed_traffic
:These tunnels are working well with our end device which is a Watchguard :Firebox x1000. Our parent company is using a PIX506 (not sure if it's the :506E) and the config looks similar to the following; : name 1.2.3.0 Site_A : name 4.5.6.0 Site_B : name 9.8.7.0 Site_C : name 6.5.4.0 Site_D : object-group network To_Networks : network-object Site_A 255.255.255.0 : network-object Site_B 255.255.255.0
The first thing you should know is that when you use 'name' in a PIX, the effect is *exactly* the same as if you had written in the address (in places where the PIX allows a name to be specified.) For example, if you had written
name 1.2.3.0 Site_A access-list Sample permit ip Site_A 255.255.255.0 host 88.77.66.55 access-list Sample permit ip 1.2.3.0 255.255.255.0 host 88.77.66.44
and you were then to show the configuration, the PIX would show it as
name 1.2.3.0 Site_A access-list Sample permit ip Site_A 255.255.255.0 host 88.77.66.55 access-list Sample permit ip Site_A 255.255.255.0 host 88.77.66.44
and if you were then to
no name 1.2.3.0 Site_A
and show the configuration again, the PIX would show
access-list Sample permit ip 1.2.3.0 255.255.255.0 host 88.77.66.55 access-list Sample permit ip 1.2.3.0 255.255.255.0 host 88.77.66.44
Thus upon encountering a known name in the configuration, the PIX immediately converts it to the IP address internally and stores it like that, and when you show the configuration, the PIX looks up each IP address and converts it to a name if a name exists for it.
[The other important tidbit about names, but not of signficance for what you are doing, is that in -most- Deny log statements, known IP addresses will be output as names, but the same is not true for Build or Translation or Teardown messages -- so if you have a name for an IP and you are searching through the logs for all information about activity on the IP, you need to search for the name -and- for the IP address.]
: object-group network From_Networks : network-object Site_C 255.255.255.0 : network-object Site_D 255.255.255.0 : access-list access_list_101 permit ip object-group From_Networks object-group To_Networks : crypto map crypto_map 10 match address access_list_101
:Is there much difference to how the two configs interact or as you mentioned :would the PIX be expecting a different SPI?
The second thing you need to know is that when have a single object-group on a configuration line, the effect is exactly the same as if you had written the same command but substituating each of the elements of the object in turn, in order; if an group-object is one of the elements, it will be completely expanded before the next element in the list is processed. If the same element is derived in multiple ways (e.g., part of two different object groups that are included in the same object), then when you look at the running configuration, -both- occurances may show up.
Thirdly, when you have more than one object group on the same command line, the rightmost one will be expanded most quickly.. e.g., if you have three of two elements each, the expansion order will be 1 1 1; 1 1 2; 1 2 1; 1 2 2; 2 1 1; 2 1 2; 2 2 1; 2 2 2
If we put this together, the effective access_list_101 that will be generated in your example above would e SITE_C SITE_A SITE_C SITE_B SITE_D SITE_A SITE_D SITE_A
If you look at the individually-specified access list you posted, you will notice that the expansion pattern was the same.
However, if you were to to construct the "mirror" access list of the object-group version, by reversing the source and destination groups, permit ip object-group To_Network object-group From_networks then the expansion order for that would be
SITE_A SITE_C SITE_A SITE_D SITE_B SITE_C SITE_B SITE_D
which you will note is -not- the exact reverse of the first expansion: the reverse of the first expansion would start with two SITE_C's as the destinations.
So... if you are using object-groups and you blindly just reverse source and destination positions in order to get the "mirror", then the result will -not- be in the same order as what the other end would think the "mirror" order was.
The question then becomes, "Does this disorder between the two sides matter?" The answer for that is, "It does if any of the ranges overlap; and it does not matter if all of the ranges are independant. In your example above, the ranges are all independant, so in your example there would not be any difficulty.
Suppose though, for example, that you had a group that included both a host 10.11.12.13 and the subnet that encompases the host, 10.11.12.0/24 . When you expand the pair of groups on one side, there will be an SPI created for the host to each of the destination elements, and a second SPI created for the subnet to each of the destination elements. The "top to bottom" rule is in effect and the sender will use the host-specific SPI when appropriate rather than the subnet based one. But that's based upon order within the expanded list, *not* upon "best match"! So if you take the same object groups and just reverse the source and destination positions on the other end, then because the generated order will end up coming out differently, the other end will end up chosing the subnet- based SPI instead of the host-based one in some cases... thus getting an SPI conflict.
To re-emphasize: you will NOT have that kind of conflict in the simple non-overlapping objects that you posted, but the problem can crop up with more complex groups that have overlapping elements.