PIX 506 IPSEC
Shane Malden
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
Walter Roberson
Shane Malden <sh...@nedlam.com> 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...?
--
History is a pile of debris -- Laurie Anderson
Shane Malden
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
"Walter Roberson" <robe...@ibd.nrc-cnrc.gc.ca> wrote in message
news:d91i7k$p5b$1...@canopus.cc.umanitoba.ca...
Walter Roberson
Shane Malden <sh...@nedlam.com> wrote:
: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.
--
"Who Leads?" / "The men who must... driven men, compelled men."
"Freak men."
"You're all freaks, sir. But you always have been freaks.
Life is a freak. That's its hope and glory." -- Alfred Bester, TSMD