[EMAIL PROTECTED] asked: >Where does the VPN box typically go? Is it an additional IOS that get >loaded onto the 1417 DSL router? Is it an IOS that gets loaded on a 2600 >that sits between the 1417 and the firewall? Is it something altogether >different? I should also note that they are NATing the entire address from >the 1417 DSL router to their existing, external, firewall which is >supporting a perimeter network. The answer is ... it depends. You can use a separate VPN function in a standalone box, or you can use a VPN function within a router or within a firewall (depending on availability). I dont know what the 1417 is, but if it's anything like most xDSL routers, it's too stupid to have a VPN function in it. (We get Cisco 675 DSL routers here and you're lucky that they have a Telnet daemon for configuration). The only serious limitation, which has come up in the past few days on this list, is that you must NAT BEFORE you do your VPN function. I'm assuming you want to use IPSEC, which has definite security benefits over PPTP. IPSEC + IKE is fundamentally incompatible with NAT---the IP addresses must not be screwed with once the IKE &/or IPSEC protocols have been activated. For that reason, if you have a firewall between the xDSL box and your internal LAN, this is an obvious place to put the VPN function, because the firewall can keep straight the firewall issue, the VPN issue, and the NAT issue, since it's doing them all. Raptor Eagle does this just fine; Firewall-1 is a little more difficult to configure. In general, the best configuration is to put a dedicated VPN box between the inside of the firewall and the LAN. But if your firewall is handling a NAT function, then this won't work. I personally prefer, in that case, to put a dedicated VPN box between the firewall and the external router. My experience is that the dedicated VPN vendors know a lot more about VPN than the firewall folks do; more specifically, they don't have to shoehorn in the concept of VPN into an existing and complex configuration. (I challenge anyone to map FW-1's VPN configuration into the relevant IPSEC RFCs; it takes dozens of menus and days of experimentation to figure out what the FW-1 word for "blah" is.) On the remote side, you typically have two possibilities: end users who are on unpredictable IP addresses (dial-in, usually) and end users who have predictable IP addresses (either branch offices, or folks on DSL/cable/ISDN who have static IPs). For remote users, you want to use a small dedicated box (Ravlin 4/Personal Ravlin from Redcreek is very good; NetScreen 5; SonicWall also can work) if at all possible. The CPU burden of 3DES on a modern machine is not substantial for speeds of 256K or so, but why screw with it (and be locked into particular versions of particular operating systems) when you can protect a whole LAN? John Adams ([EMAIL PROTECTED]) also added: >It really depends on what you're trying to achieve with the VPN; if you're >trying to connect two networks together, then it's simple because you can >use a pre-shared secret and not deal with a certificate server. Pre-shared secrets are bad. They're OK for the purposes of getting something up and running quickly, but they devolve to saying "username/password is all the security I need." Since most of us have spent the last ten years trying to dig ourselves out of username/password authentication, I'm loathe to recommend anyone use it if they don't have to. Of course you could change your PSS once a week like a diligent network manager, but no one I know outside of the military has that kind of discipline. If you don't want to use certificates (why not? It's easy enough, if your vendor supports them), then at least use raw public keys to dramatically increase the entropy in the equation. >If you're trying to assign and manage certificates for individual users, >then the way it works is this (someone correct me if this is wrong because >I haven't implemented it yet, and we're going to implement this in a week >or so): >1) You get a certificate server (i.e. NAI's PGP PKI Server) >2) You install the signing CA's certificate on the router >3) You tell the router where the PKI server is on the internal network >4) You create keys for people and load the certs (now signed by your CA) > into the client software (PGPNet, Cisco's VPN Client, etc.) >5) You create cryptomaps to map VPN traffic from the outside clients into > the NAT. Step (3) is not necessarily valid for all hardware & CAs. The on-line communication between a VPN box and the CA is generally limited, at best. I don't believe that many vendors do on-line CRL (certificate revocation list) lookup. In addition, many VPN vendors have their own proprietary CAs built into their product or management station, so you don't have to blow big bucks for a CA just for this. Of course, if you are doing a full-fledged PKI installation for more than VPN, a CA is a good idea. If it's just for a hundred people dialing in remotely, then the proprietary CA probably integrates better and offers better revoked/blocked certificate support than something like NAI. jms Joel M Snyder, 1404 East Lind Road, Tucson, AZ, 85719 Phone: +1 520 324 0494 (voice) +1 520 324 0495 (FAX) [EMAIL PROTECTED] http://www.opus1.com/jms Opus One - [To unsubscribe, send mail to [EMAIL PROTECTED] with "unsubscribe firewalls" in the body of the message.]
