Yeah, the IPSec GUI needs some work. We're revamping it for Whistler.
If you're creating an L2TP+IPSec VPN, whether client-to-gateway or
gateway-to-gateway, the IPSec part of it is completely automatic. The IPSec
policy is dynamically generated when the machines establish the L2TP tunnel.
You actually don't ever go into the IPSec policy GUI in this instance. Note
L2TP+IPSec requires some kind of PKI, unless you want to do a little work.
(See shameless plug below.)
If you want to create an IPSec transport mode SA between two nodes, or you
want to build a pure IPSec tunnel between two gateways, then you use the
IPSec policy GUI instead of the VPN GUI. Nice, eh? :) Go here: Start ->
Programs -> Administrative Tools -> Local Security Policy; choose "IP
Security Policy on Local Machine" in the left pane. When you add a rule to a
policy, one of the steps in the wizard asks if the rule specifies a tunnel.
If you say "yes" and specify a tunnel endpoint, then you've got pure IPSec
tunnel mode. If you say no, then you've got IPSec transport mode.
Now about my little "routable on the network behind the gateway" comment.
There's lots of interest in using pure IPSec tunnel mode for
client-to-gateway remote access. But since IPSec lacks address assignment
and user authentication, we simply don't support it, officially. In nearly
all remote access scenarios, it won't work anyway since the client gets an
IP address from their ISP that of course isn't routable inside the network
the client really wants to tunnel to. Now if you're in a rare situation
where your NIC's (or modem's) IP address is routable in the network behind
the IPSec gateway, then of course tunnel mode will work just fine. We
haven't made this something very intuitive to set up, since it's not really
a "VPN" -- you do it the same way you do for gateway-to-gateway IPSec tunnel
mode (see above paragraph). IPSec really doesn't care whether you're a
gateway or a client anyway.
As an aside, here's where I see almost all of our VPN work happening:
1. PPTP if there are any downlevel clients (9x/Me/NT) involved in
client-to-gateway tunneling. With the 128-bit encryption pack, MS-CHAPv2
authentication, and strong passwords, PPTP is pretty secure, and also quite
fast on Windows 2000 RRAS servers (the code is quite well optimized).
2. L2TP+IPSec tunneling for Windows 2000 clients involved in
client-to-gateway tunneling. This requires some kind of PKI, since the
dynamic IPSec policy is designed to use certificates for authentication.
(You can create your own IPSec policy for L2TP+IPSec if you prefer to use
preshared keys, but it's painful. Somewhere around here I have the steps...)
Any kind of cert will work as long as it provides machine authentication and
shares a root or intermediate in common with the RRAS server. Plug: if you
use the Windows 2000 CA and all your clients are in an Active Directory
domain, you can set up an AD group policy to automatically issue machine
certs to all clients when they join the domain. Almost a self-maintaining
PKI! hehe. And in Whistler, we'll have user cert auto enrolling, too.
3. IPSec transport mode for typical things: securing the traffic between
Alice and Bob. No tunneling going on here.
4. L2TP+IPSec tunneling or pure IPSec tunnel mode for gateway-to-gateway
tunneling. You know, two private networks using the Internet as their
transport. Pure IPSec tunnel mode is of course more "elegant," but right now
it's a little more difficult to manage. L2TP+IPSec tunnels appear in the
RRAS MMC as routable interfaces, meaning that they're easy to manage and
instrument with SNMP or WMI.
You can do a little NAT magic with L2TP+IPSec tunnels if you want to -- on
the same Windows 2000 RRAS box you can NAT all your traffic before running
it through a tunnel, which is useful if you need all the traffic leaving one
of the private networks to have a public address. I had to do this for one
customer because the second network wouldn't add any static routes sending
return traffic back out their RRAS box. NATting the first network to a
public address means that return traffic just goes out the second network's
default route and then makes it back to the first network. This is NATting
followed by encrypting; we can't go the other way -- encrypting followed by
NATting -- for all the usual reasons.
L2TP+IPSec does add a little overhead over pure IPSec tunnel mode, but on
fast computers with hardware IPSec offload, you really don't notice it all
that much. You'll be bandwidth-constrained long before you exhaust a beefy
server's resources.
I'm on vacation this week (but like a good Microsoftie, can't stay away from
e-mail!). I'll dig up that interoperability info and forward it on to the
list next week.
_______________________________________________________
Steve Riley
Microsoft Communications Consulting in Denver, Colorado
[EMAIL PROTECTED]
+1 303 521-4129 (OLD mobile)
www.microsoft.com/isn/
Applying computer technology is simply finding the right wrench to pound in
the correct screw.
-----Original Message-----
From: Ben Nagy [mailto:[EMAIL PROTECTED]]
Sent: Sunday, January 14, 2001 3:52 PM
To: Steve Riley (MCS); [EMAIL PROTECTED]
Subject: RE: PIX & Win2K IPSec
Hi Steve,
> -----Original Message-----
> From: Steve Riley (MCS) [mailto:[EMAIL PROTECTED]]
> Sent: Saturday, 13 January 2001 6:23
> To: Brian Ford; [EMAIL PROTECTED];
> [EMAIL PROTECTED]
> Subject: RE: PIX & Win2K IPSec
>
>
> The question was about pure IPSec tunnel mode, not about L2TP+IPSec.
>
> Officially, we don't support pure IPSec tunnel mode for
> client-to-gateway configurations unless the client has an IP address
> that's routable on the network behind the gateway. Pure IPSec tunnel
> mode doesn't have any way of assigning tunnel end-point IP
> addresses to
> clients, thus the need for L2TP or some other kind of VPN client shim.
So you're saying that you _do_ support native IPSec tunnel mode without the
L2TP addition? That's good news. I had a peek and saw no obvious way to
select between IPSec+L2TP and vanilla IPSec. I assume it's a "trick"?
Is there some weird problem you're referring to with your "routable on the
network behind the gateway" comment? I find that default routes work fine
for me, using gateway<-->gateway meshes. I don't understand why it would
cause any more of a problem with client<-->gateway. I guess in some sense
client is a bit of a misnomer if it's tunnel mode anyway.
>
> Trevor, what's the scenario for your test case? Does the
> client have an
> address that's routable on the network behind the PIX? We've got some
> specific interoperability config info I can forward to you.
Please keep this on the list? It's on topic, as far as I can see...
> ____________________________________________________
> Steve Riley
> Microsoft Communications Consulting in Denver, Colorado
> [EMAIL PROTECTED]
> +1 303 521-4129 (OLD mobile)
> www.microsoft.com/isn/
> Applying computer technology is simply finding the right
> wrench to pound
> in the correct screw.
Cheers,
--
Ben Nagy
Marconi Services
Network Integration Specialist
Mb: +61 414 411 520 PGP Key ID: 0x1A86E304
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
