PIX 506 IPSEC

Hi, Quick question for you all. When using the group commands (object-group network) with an IPSEC configuration, does the other firewall that terminates the IPSEC with a 506 need to support groups or will the PIX strip these down one to one. Eg, we have two brands of Firewalls, our Parent company is trying to establish a VPN to a non PIX Firewall. They have used 'name' commands (name 1.2.3.0 name_Subnet) and 'object-group' commands (object-group network Subnet_name, network-object name_Subnet

255.255.255.0) in the configuration. Our firewall has one to one routing policies (eg. 1.2.3.0 -> 9.8.7.0). We do have other PIX firewalls that connect to us but they use acls explicit one to one. Does anyone have any information on interoperability for the PIX 506 (506E).

Regards, Shane

Reply to
Shane Malden
Loading thread data ...

In article , Shane Malden wrote: :Hi, Quick question for you all. When using the group commands (object-group :network) with an IPSEC configuration, does the other firewall that :terminates the IPSEC with a 506 need to support groups or will the PIX strip :these down one to one.

It will reduce them to primitive elements specified by the protocol.

: Eg, we have two brands of Firewalls, our Parent :company is trying to establish a VPN to a non PIX Firewall. They have used :'name' commands (name 1.2.3.0 name_Subnet) and 'object-group' commands :(object-group network Subnet_name, network-object name_Subnet :255.255.255.0) in the configuration.

There is something you need to watch out for:

When you are using object-groups as policy mechanisms (e.g., you want to permit through SMTP servers and DNS servers, so you build an SMTP server group and a DNS server group, and build a group that includes those two groups), then it is not uncommon for you to end up with duplicated elements within the expanded group. Particularily if you have objects in both the source and destination fields, when the objects are fully expanded, you can end up with overlaps. If H is a member of subnet S, and the object includes both H as a host and S as a subnet, then the exact crypto ACLs that are generated will depend on the details of the object expansion algorithm and on the relative orderings of H and S within the including objects. If you are not very careful on the other end to reconstruct Cicso's expansion algorithm, then you may end up with a crypto ACL on the other end that resolves the overlaps differently and thus tries to send return packets with a different SPI than the PIX is expecting...

This can certainly happen without objects too, but when one is using objects, it is easier to overlook the issue, forgetting that (e.g.) a DNS server might also be an SMTP server... Thus, at all times but -particularily- when using objects, it is important that the primiative IPSec ACL elements be precisely mirrored between the two ends. E.g., If the other end is using objects too, make sure that every group has -exactly- the same content in -exactly- the same order -- if the same elements are there but in a different order, then you might have trouble.

If, though, your object group is as simple as the one you indicate above, the effect is just going to be as if you had directly written the one subnet at that point, and the sandbox is too small to get in much trouble in.

:Our firewall has one to one routing :policies (eg. 1.2.3.0 -> 9.8.7.0).

If the packets being sent through the VPN are being NAT'd [e.g., into your public IP space] rather than the private IP spaces of both ends being exposed to each other (e.g., via nat 0 access-list), then there is a trick you have to know, which is that on the PIX, the crypto map ACL for NAT'd packets must be written in terms of the *post* NAT addresses, rather than in terms of the internal addresses.

If the other end is also doing NAT, then it's crypto map ACL may end up looking completely different!

Consider for example, if internal range 1.2.3/24 is being source IP translated to 9.8.7/24 when transmitting to a remote device that is using internal range 21.22.23/24 that is source IP translated to 29.28.27/24:

[internal source 1.2.3/24] -> [public source 9.8.7/24] [public destination 29.28.27/24] -> [internal destination 21.22.23/24]

then on the originating PIX, the crypto map ACL would have to be permit ip 9.8.7.0 255.255.255.0 21.22.23.0 255.255.255.0 because the crypto map has to be in terms of what the packets contain after outgoing NAT. If the destination device is a PIX, then the crypto map ACL on it would have to be permit ip 29.28.27.0 255.255.255.0 9.8.7.0 255.255.255.0 which is a neat enough reversal that my point doesn't come through strongly enough ;) If you overlapping IP ranges or otherwise find yourself needing to use "reverse NAT" and you work through an example, you will find that the ACLs turn out not to be nicely symmetrical.

You need to be aware, though, that not all kinds of devices want the equivilent to the crypto map acl to be in post-NAT format. Even just CISCO's IOS, there was a transition point somewhere in

12.3: the IOS crypto maps have to be written one way for earlier versions, and a different way for later versions. And as to what other manufacturers' devices do...?
Reply to
Walter Roberson

Walter,

Thanks for your reply. Not sure if I'm more confussed.

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

On a watchguard you configure the Gateway which contains the phase1 seetings, then a Tunnel which contains all the phase2 settings. Then lastly you configure the Routing policies which is a subnet to subnet approach.

The comments about SMTP and DNS (S/H), I'm not sure I understand that. If you are able to give me more information to understand the difference to the above samples, it would be appreciated.

Regards, Shane

(object-group

Reply to
Shane Malden

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

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.