I'm helping a small company with setting up a VPN between their 2
offices. Currently considering PIX 501s for them as they seem to
support their needs and can be upgraded as they add people in the
offices. But they have a requirement that I cannot confirm that the
PIX will handle as needed so here is the list of requirements and my
thoughts:

Firewall/DHCP/NAT - PIX should be fine with this

VPN between 2 offices, static IPs - PIX should have no problem here

VPM to roaming sales people on dynamic IPs - PIX with Cisco VPN client
on laptops should be fine I think.

VPN through PIX to Netgear VPNs at vendors sites - This is where I am
not sure it will work. Reading the info on the PIX 501 at Cisco site
states that a single internal device can do a VPN pass through,
problem is that they may have 3 or 4 people doing VPN into remote
sites at the same time. Internal users will have the Netgear VPN
client s/w installed on their computers.

Advice on what to get or if the 501 will do all they need?

In article <c7f4fcca.0411261810.17cb3da7@posting.google.com>,
no one <sweazle@hotmail.com> wrote:
:I'm helping a small company with setting up a VPN between their 2
ffices. Currently considering PIX 501s for them as they seem to
:support their needs and can be upgraded as they add people in the
ffices. But they have a requirement that I cannot confirm that the
:PIX will handle as needed so here is the list of requirements and my
:thoughts:

:Firewall/DHCP/NAT - PIX should be fine with this

Yes.

:VPN between 2 offices, static IPs - PIX should have no problem here

Yes.

:VPM to roaming sales people on dynamic IPs - PIX with Cisco VPN client
n laptops should be fine I think.

Yes, with a limit of 10 total VPN peers including the ones between the
two offices.



:VPN through PIX to Netgear VPNs at vendors sites - This is where I am
:not sure it will work. Reading the info on the PIX 501 at Cisco site
:states that a single internal device can do a VPN pass through,
roblem is that they may have 3 or 4 people doing VPN into remote
:sites at the same time. Internal users will have the Netgear VPN
:client s/w installed on their computers.

If the Netgear VPN supports NAT Traversal, then this will not
be difficult to impliment, provided the PIX are at 6.3(1) or later
[they should be at 6.3(4) due to security problems earlier 6.3]

The command to use on the PIX would be isakmp nat-traversal 20

Once this is set up, ensure that you do not have udp port 4500 filtered
between you and the remote sites, and the PIX should take care of the
rest, provided the Netgear box cooperates.

The places that talk about being limited to a single VPN pass through
are to do with the 'isakmp esp-like' to allow the ESP protocol to
pass to a -single- PAT'd device. This is not necessary if you have
nat-traversal support: nat-traversal encapsulates ESP and AH packets
inside of UDP packets to get them through the network.

If you did happen to turn on 'isakmp esp-like' you would lose your
ability to do site-to-site VPNs such as you list in your second requirement.

'isakmp esp-like' is only of use if you are using PAT (Port Address
Translation.) If you are using NAT (Network Address Translation) so that
each internal user that is trying to VPN out will be able to have their
own publically routable IP address, then you do not need either esp-like
or nat-traversal (well, nat-traversal still helps in that it allows AH
over NAT, which is normally not possible.)

The issue that esp-like is trying to deal with is that the ESP protocol
does not -have- "ports" that might allow multiple internal IPs to be
mapped to the same external IP with the reverse-mapping able to be done
by looking at the "port". If you use are able to give each VPN'ing user
a unique public IP (even if only temporary via a 'global' with
an address range) then the destination system can be determined by the
IP and the problem goes away.



:Advice on what to get or if the 501 will do all they need?

All the other models of PIX have the same limitations as the 501,
with the exception that the other models allow more simultaneous
VPN peers. Thus if you do not have public IPs available and the
Netgear VPN does not support nat-traversal, you will either have to
find some other solution entirely or else you will have to use
a different firewall than the PIX line [and you'd probably end up
with the same translation issues.]
--
Cannot open .signature: Permission denied

roberson@ibd.nrc-cnrc.gc.ca (Walter Roberson) wrote in message news:<co90ej$627$1@canopus.cc.umanitoba.ca>...

First, thank you for you help.

OK, looks like the Netgear client will support NAT traversal. From
their site on their client it says:
"Includes Network Address Translation (NAT) traversal support for VPN
clients behind devices that support VPN pass-through mode."

So looks like they will be able to have their 3 or so people connected
to the vendor sites simultaneously.

Ah, thanks for the explination.

OK, will need NAT traversal. Will be a many to one NAT setup so they
will be sharing the external address.

One thing that your post made me realize is that the 501 is limited to
10 concurrent tunnels. My original thought was that if 10 wasn't
enough, I could get the 50 user license and assumed that the number of
tunnels would also go up but that seems not to be the case. While they
would never need 50 concurrent tunnels, 10 may be a little low for one
of the offices based on future plans.

Hmm, actually 10 may be fine. If the Netgear clients are doing NAT
traversal then they are not using a VPN tunnel, correct? So I could
have a 501 with 50 user upgrade and the 10 tunnels would be available
for site-to-site and remote users running the Cisco client which would
be more than enough.

In article <c7f4fcca.0411271119.30a80f24@posting.google.com>,
no one <sweazle@hotmail.com> wrote:
:One thing that your post made me realize is that the 501 is limited to
:10 concurrent tunnels.

:Hmm, actually 10 may be fine. If the Netgear clients are doing NAT
:traversal then they are not using a VPN tunnel, correct?

Correct.

:So I could
:have a 501 with 50 user upgrade and the 10 tunnels would be available
:for site-to-site and remote users running the Cisco client which would
:be more than enough.

Yes. The limit of 10 on the 501 is on the number of isakmp peers that
the 501 itself is talking to (including people connected via the Cisco
VPN software client using the 501 to access the LAN.) PIX don't care
how many active nat traversals you have.

One point of advice that I offer is that if you are in the situation of
needing more than about 20 or 25 "licenses" on the 501, then -usually-
you would be better off skipping the 501 and 50 user upgrade and going
directly to a 506E. The 506E has no user limit and is a noticably
faster device, and allows up to 25 isakmp peers. The 50 user upgrade
to a PIX 501 costs roughly half of the price difference between a 501
and a 506E, so for a few hundred more dollars you could have a device
that would likely serve you longer.


You indicated that the users will be sharing one external IP address;
in that case, the 501+50 might be good enough for you. You need to
understand what the license is counting, though, to make a proper
decision.

The 10 or 50 "user" license doesn't really count users at all. What it
counts is the number of internal devices that have simultaneously
active translations to the outside. That translation might be via a
'static', a 'nat 0', or via NAT or PAT. static and nat 0 translations
do not become "active" until the first time traffic goes over them, but
once they become active, they stay active until the next reboot or the
next "clear local-host" command is issued: once active they do not
expire. Regular NAT and PAT translations do expire; any particular
internal host which closes all its TCP connections and stops talking
through UDP, will be removed from the license count a short
(undocumented, not configurable) time (< 30 seconds in my experience)
after the last translation for the host expires.

There's an important factor to consider for this license count, and
that is this: when an external host attempts a connection from outside,
then the translation is built [and the license counted] *before* the
ACLs are checked. If you have a number of IP addresses that are routed
to the PIX, or which the PIX is accepting connections for by way of
proxy arp (usually the case for any external IP that is covered by a
'static' command), then if there is any external to internal
translation defined for that external IP, the connection attempt will
use up a license temporarily even if the ACL prohibits that actual
source/destination tuple. The implication is that if you have a number
of external IPs, then each of the #$@!# network probes that are
constantly active on the net these days, can end up temporarily using
up a license. You can thus end up running out of licences because of
people probing you hoping for security leaks, even though you only have
a handful of machines on your LAN.

As I indicated earlier, this last problem isn't going to be a real
issue for you if you only have a single external IP (unless you start
using static port address translations); it can be a big nusiance in
some situations, though. Particularily for people who blithely do
address mapping by using a 'static' with a netmask other than
255.255.255.255: they might only have (say) 3 -real- internal hosts,
but the PIX doesn't know that when it is counting licenses.
--
Admit it -- you peeked ahead to find out how this message ends!