VPN Concentrator Behind PIX?
sefoca
We have a pix 515 which is our only access to the internet. (No routers).
I see that I can put the VPN 3000 behind the Pix, and I would like to do
this.
I can't find any documentation for this on cisco.com. It's all Concentrator
to Network Device, instead of Concentrator through Network Device.
Anyway, I'm wondering what conduits / acl permits I need to put on the Pix.
I'm also a little confused by the routing.
Here is my setup
Pix e0 64.64.64.1 --- Pix e1 192.168.10.1
VPN Pub: 64.64.64.3 --- VPN Priv 192.168.10.3
There is a default route on the VPN to 64.64.64.1, and I can ping the
internet from the VPN.
But my users cannot connect to the VPN.
Do I need a tunnel route? Or a route on the Pix to ... where?
Thank you.
sefoca
If my VPN (64.64.64.3) is inside the PIX, do I need to do a static nat for
it?
Or just permit various vpn protocols to get to the vpn host? (In which
case, I think I would need some sort of route statement on the pix?
Oh well, thanks again.
Confused
"sefoca" <no...@none.net> wrote in message
news:coth8k$b...@library1.airnews.net...
Walter Roberson
:A thought just occurred to me:
:If my VPN (64.64.64.3) is inside the PIX, do I need to do a static nat for
:it?
Or equivilent, such as nat 0 access-list . A VPN concentrator is
a "server", and you have to tell the PIX -somehow- to allow the
packets to get to the right place. That's a two-part job in PIX:
configuring the ACLs to permit the packets, and configuring the PIX
to get the packets through to the right internal machine.
:Or just permit various vpn protocols to get to the vpn host? (In which
:case, I think I would need some sort of route statement on the pix?
Ummm, are you talking about the IPSec or PPTP traffic -to- the
VPN concentrator [i.e., the tunneled traffic], or are you talking
about what happens after that traffic is de-encapsulated?
To answer your question of what to let through: it depends on which
types of VPN you want to support. Normal IPSec uses the ESP IP protocol
(it's not a port, it's a protocol just as 'tcp' is a protocol),
and uses UDP port 500 (isakmp), and may use the AH IP protocol
if you have configured for AH.
If you have configured support for IPSec NAT-T (NAT Traversal), then
you need UDP port 500 (isakmp), and UDP port 4500, and an additional
port may be dynamically opened; in this situation, the ESP and AH
protocols do not need to be accessible [but if ESP is accessible then
ESP packets will go directly; if you have configured IPSec to request
AH, then if you have NAT-T turned on, then the AH protocol will be used
only if the protocol is reachable and there is no NAT anywhere along
the route [AH and NAT are philosophically incompatible.]
The original implimentation of NAT-T used UDP port 10000 instead
of UDP port 4500, so you will see that sometimes.
If you are using L2TP, then because L2TP is layered on top of
IPSec, the requirements are as indicated above.
If you are using PPTP, then my recollection is that you need
UDP port 500 (isakmp) and the IP protocol GRE.
NB: the IP protocols ESP and GRE will work with one-to-one NAT,
but [in the absence of NAT-T support] the IP protocol AH will only
work if there is no address translation (the public IP is the
same as the private IP.) In the absence of NAT-T support, PIX 6.3
can be configured to support *one* PAT'd VPN tunnel -through- the PIX...
but if you activate that feature then you cannot have any VPN tunnels
ending -at- the PIX.
--
And the wind keeps blowing the angel / Backwards into the future /
And this wind, this wind / Is called / Progress.
-- Laurie Anderson
John Smith
concentrator in parallel with the pix... the external int. of the conc. will
have a public ip (just like the pix) and the internal interface of the conc.
will be connected to a dmz interface of the pix. this way , those coming
thru on the vpn can still be firewalled...
"sefoca" <no...@none.net> wrote in message
news:coth8k$b...@library1.airnews.net...
sefoca
"> :If my VPN (64.64.64.3) is inside the PIX, do I need to do a static nat
for
> :it?
>
> Or equivilent, such as nat 0 access-list . A VPN concentrator is
> a "server", and you have to tell the PIX -somehow- to allow the
> packets to get to the right place. That's a two-part job in PIX:
> configuring the ACLs to permit the packets, and configuring the PIX
> to get the packets through to the right internal machine.
>
I guess my confusion is this: I do not have a 3rd card (DMZ) in the pix.
Is there a way to put the concentrator behind the pix if the pix just has
public and private interfaces?
I should have spelled that out previously, I'm sorry.
The problem is, if I assign a public IP to the vpn concentrator, I don't see
how I can do a static nat for that same IP on the pix. The statement would
be something like "static (inside,outside) 64.64.64.3 64.64.64.3".
sefoca
"John Smith" <jsm...@macroshaft.com> wrote in message
news:ibydnV1mYep...@giganews.com...
> just a little fyi, cisco's official recommendation is to place the
> concentrator in parallel with the pix... the external int. of the conc.
will
> have a public ip (just like the pix) and the internal interface of the
conc.
> will be connected to a dmz interface of the pix. this way , those coming
> thru on the vpn can still be firewalled...
Thanks, I didn't realize that was the recommendation. I've seen marketing
material that says you can put the thing just about anywhere -- outside,
inside, parallel....
Unfortunately, I only have two cards in the pix. It's a 515 so I have space
for a DMZ, I just need to get the concentrator in place for the time being.
Thanks again.
John Smith
"sefoca" <no...@none.net> wrote in message
news:couvr6$v...@library2.airnews.net...
sefoca
When you said the concentrator was essentially a server, I realized that it
might be possible to treat it thus.
I unplugged the outside interface of the concentrator.
I did a static translation of the inside interface.
I allowed the protocols you mentioned.
conduit permit gre host 64.---.---.3 any (hitcnt=67)
conduit permit esp host 64.---.---.3 any (hitcnt=521722)
conduit permit ah host 64.---.---.3 any (hitcnt=0)
conduit permit udp host 64.---.---.3 eq isakmp any (hitcnt=9)
conduit permit udp host 64.---.---.3 eq 10000 any (hitcnt=0)
And it works. Sort of.
Most of the people connecting are behind a 3002 VPN HW Client.
They are now able to connect to the concentrator well enough to get out to
the internet.
(These 3002s advertise split tunneling, but if their head-end (the
concentrator) goes down, then they go down.)
I am still not able to ping the remote 3002s. I suspect I need a route
statement on the pix.
Here's what I have:
PIX# sh route
outside 0.0.0.0 0.0.0.0 64.---.---.1 1 OTHER static
outside 64.---.---.0 255.255.255.248 64.---.---.2 1 CONNECT static
inside 192.168.10.0 255.255.255.0 192.168.10.1 1 CONNECT static
I *think* I need another outside route that tells my computers here how to
reach the remote clients. I'm not sure if I need to point it to the
internal address of the VPN concentrator, or the NATted address of the VPN
concentrator.
I guess I'll try both after hours and see what happens.
Thanks again for your input.
Walter Roberson
:I guess my confusion is this: I do not have a 3rd card (DMZ) in the pix.
:Is there a way to put the concentrator behind the pix if the pix just has
:public and private interfaces?
Certainly possible.
:The problem is, if I assign a public IP to the vpn concentrator, I don't see
:how I can do a static nat for that same IP on the pix. The statement would
:be something like "static (inside,outside) 64.64.64.3 64.64.64.3".
You can static an IP to itself; PIX refers to that as "Identity NAT".
It has the effect of sayin "This IP address is on the inside, and it
is okay to allow new connections to be made to it, provided those
connections satisfy the ACLs."
What you need to watch out for is that the PIX does not allow two
interfaces to have the same IP address range. As I have posted
the work-arounds for this before, I'll just point you to them rather
than retyping them:
http://groups.google.ca/groups?selm=br5nb8%24p2i%241%40canopus.cc.umanitoba.ca
--
Take care in opening this message: My grasp on reality may have shaken
loose during transmission!
Walter Roberson
:Well, here's what I did.
:When you said the concentrator was essentially a server, I realized that it
:might be possible to treat it thus.
:conduit permit gre host 64.---.---.3 any (hitcnt=67)
:And it works. Sort of.
Sorry, I don't debug configurations that include conduits. As soon as
Cisco started allowing ACLs access-group'd to interfaces, they started
discouraging conduits, and within a few subreleases they started
officially saying that conduits were deprecated. That was in 5.3(2) if
my memory serves. There were some bugs in the interaction of conduits
and ACLs that Cisco -tried- to fix in the 5 series releases. By the
time of 6.0, Cisco started running into bigger problems with conduits
not working properly with new features, which they worked on through
6.0 (which didn't last very long). By 6.1(1) Cisco started admitting
there were substantial bugs with conduits, and by 6.2(1), gave notice
that conduits were not going to be supported in 7.x and that Cisco was
no longer going to try to fix the conduit problems.
It is my philosophy that there is no point in taking time to try
to debug problems with conduit configurations when the problems might
be due to long-standing bugs in the implimentation that won't be fixed.
And 7.x with no conduit support will be out Real Soon Now (they are
now quite a bit behind on releasing it; it went into beta testing
at the beginning of the year.)
--
When your posts are all alone / and a user's on the phone/
there's one place to check -- / Upstream!
When you're in a hurry / and propagation is a worry/
there's a place you can post -- / Upstream!
Walter Roberson
:"John Smith" <jsm...@macroshaft.com> wrote in message
:news:ibydnV1mYep...@giganews.com...
:> just a little fyi, cisco's official recommendation is to place the
:> concentrator in parallel with the pix... the external int. of the conc.
:will
:> have a public ip (just like the pix) and the internal interface of the
:conc.
:> will be connected to a dmz interface of the pix. this way , those coming
:> thru on the vpn can still be firewalled...
:Unfortunately, I only have two cards in the pix. It's a 515 so I have space
:for a DMZ, I just need to get the concentrator in place for the time being.
If you are using the PIX 6.3 software release, then your 515 will
support "logical interfaces", which is a virtual interface with a different
IP address range placed onto a physical interface. You can have
several logical interfaces with different IP ranges on the same physical
interface. In order for this to work, though, you have to have
a router or switch with IEEE 802.1Q VLAN support: each logical
interface corresponds to a different tagged VLAN.
--
Any sufficiently advanced bug is indistinguishable from a feature.
-- Rich Kulawiec
