Derek Balling wrote: > > >Yeah.. i also prefer IPSec! Aren't W2000 and XP Clients supposed to support > >IPSec VPN aswell ?
Yes, and they can interoperate with FreeS/WAN: http://www.freeswan.org/freeswan_trees/freeswan-1.95/doc/interop.html#win2k That is, you can build encrypted tunnels with Linux on one end and Win 2K or XP on the other. > >I think i'll go the Free S/Wan way aswell.. am i right, that > >i actually have to install it on the firewall or can i use a second > >machine in a DMZ ? > > I know with PoPToP, you can run it on the firewall itself, because > (until I get a dedicated machine), that's what we're doing. :-) I'd > presume you can do the same thing with Freeswan. It is commonly run on firewalls, but can run on any machine you need it on. Putting a FreeS/WAN security gateway in the DMZ might be problematic. There would be unencrypted traffic between the FreeS/WAN gate and the firewall and it isn't clear whether or how you could secure that. If an intruder captures another DMZ machine -- say a web or mail server -- he might be able to read data you wanted kept secure, bypassing your VPN. I'm not certain such a setup is entirely ruled out, but it looks tricky. Putting the IPsec gateway behind the firewall has other problems. For one thing, if your firewall does NAT, there's a basic conflict. IPsec wants to authenticate packets on an end-to-end basis while NAT wants to rewrite headers somewhere in the middle. this can be dealt with, but it complicates life: http://www.freeswan.org/freeswan_trees/freeswan-1.95/doc/firewall.html#NAT Even without NAT, the question of how to implement your security policies gets more complex if encrypted IPsec traffic passes through your firewall. You cannot do port filtering, proxying, etc. at the firewall since the packets passing there are opaque, so you need to set up some controls on the decrypted packets somewhere else. Putting IPsec on the firewall is quite a common practice, but it too may have some problems. For one thing, it may raise resource issues: http://www.freeswan.org/freeswan_trees/freeswan-1.95/doc/performance.html#performance Arguably, it also violates the security principle of keeping each service on a separate machine so a hole in one service doesn't give away too much. On the other hand, there's a pretty good argument that IPsec and firewalling belong together since both work with packets and implement security policies. You can also put an IPsec gateway "beside" the firewall rather than on it, in front of it or behind it. For example, to support telecommuters and/or "Road warrior" connections, you can use dedicated IPsec gateways into the corporate network, rather than havibg them connect via the firewall. Of course you also need some firewalling on those gateways, but if only IPsec connections are allowed there, you have a gead start on that. Anyone talking to that gateway has already authenticated to IPsec, so perhaps you can trust them some. A paper on using this approach in a corporate setting: http://www.quintillion.com/moat/lisa/ I don't know if it has been used, but another approach that puts the IPsec gateway "beside" the firewall might be worth a look. Give the firewall four interfaces, the usual three -- inside, wild side and DMZ -- plus one that goes only to your IPsec gateway. Let that gateway speak only IPsec to the outside world. Apply whatever rules you like to the unencrypted packets going between the IPsec box and your inside. This puts IPsec on a dedicated box, so it avoids the resource and two-service issues of having it on the firewall. the IPsec gateway is neither in the main DMZ nor inside your security permimiter, so some complications there are avaoided. It leaves all the firewalling in one place, on the firewall. It may complicate the rules a bit, but that doesn't look awful.
