Re: More VPN info

[Jason Costomiris]

On Saturday, February 1, 2003, at 03:17  PM, Dick St.Peters wrote:

net1 <--> net2/net3

This requires good network planning.

No, this requires planning your network around IPsec, which is not the
same thing as good network planning.  Other VPN technologies fit into
the network you have ... or that you may want to have for other
reasons.

That's silly. Planning your network so that you can aggregate the networks at each site into a single network has nothing to do with planning your network around IPsec. It has everything to do with minimizing configuration of whatever connectivity solution you deploy, be it IPsec, some random VPN, private links or even frame relay.

I take it you don't use traceroute or tracert ... and you expect the
admin to go to the remote site when he/she needs to reconfigure its
gateway.

Hm. I find traceroutes on VPNs like this to be pretty boring. There's one hop between my system and the remote system, assuming a single subnet on each end, like this. If you've lost connectivity between the sites and the Internet is working, then you've narrowed the problem right down, haven't you?

The gateways are just endoints only if you use specialized boxes.
They can just as easily be general computers performing other roles
such as providing services.  One of my systems is currently an
endpoint for 12 VPN tunnels using 4 different VPN technologies and at
the same time is a pop3, smtp, www, and ftp server.

That's nice, but in any security policy that I'd write, this would be a huge red flag... IMHO, you let your firewall be a firewall (and terminate VPNs on it if that's required) and you let your servers be servers. Never shall the two merge. It's the difference between a single system compromise giving away the keys to the kingdom versus a foothold. That foothold can be taken away from an attacker.

And remain VPN novices ...

Not at all. Just because you've got a comprehensive solution that's backed by a vendor doesn't mean you don't use and understand the technology you're using. It means you've got someone to call when you find yourself in over your head. And remember, just because it's vendor supported, doesn't mean it doesn't have to be Open Source.

The question was asked on a RedHat list, so presumably the poster has
RedHat, meaning he already has one good open source VPN solution
(CIPE) and already has the tun/tap kernel driver used by at least two
other easily-added open source VPN solutions (OpenVPN and VTun).  He
also has ppp and both stunnel and ssh, so he has a choice of many VPN
solutions.

I can't recommend against non-IPsec VPNs strongly enough. Interoperability is key. How about the first time they need to connect to a partner extranet? I bet that partner is using something that does IPsec.

Recommending solutions like ppp+ssh forwarding is like telling him to build a wooden fence with bubble gum and duct tape rather than nails. There's a cost involved in upkeep too. Long term, half-baked solutions aren't maintainable...

You want to recommend they use a non-vendor solution? Great! Recommending something interoperable is the way to go. In this case, that's freeswan.

--
Jason Costomiris <><
E: jcostom {at} jasons {dot} org / W: http://www.jasons.org/
Quidquid latine dictum sit, altum viditur.



--
redhat-list mailing list
unsubscribe mailto:[EMAIL PROTECTED]?subject=unsubscribe
https://listman.redhat.com/mailman/listinfo/redhat-list