D&C Lug - Home Page
Devon & Cornwall Linux Users' Group

[ Date Index ][ Thread Index ]
[ <= Previous by date / thread ] [ Next by date / thread => ]

Re: [LUG] VPN? & BBQ



Simon Robert wrote:

I have been "requested" to find out about Virtual Private Networks,
linking up various Redhat 9 boxes. Does anyone know of any info sources,
an idiots guide to VPN type of thing? 

I use to do a lot of this for work - but not with raw Linux.

We tended to use the firewalls we sold (which was Watchguard who paid
for iptables development so it was all "Linux inside"), although for
Voice over IP (i.e. rich companies with lots of bandwidth) we were
partnering with a company doing a dedicated hardware device giving lower
latency on the packet encryption, probably no longer necessary
processors being what they are these days.

Or/and does anyone have any
experience of running a VPN? Is it easy? Does it work? 

For as long as you have a good grasp of IP networks and routing it is
fairly easy. The good grasp of IP is needed for recognising what failed
when, and sorting out other related issues like your routing, and
checking it really is encrypted.

Interoperability between different IPSec implementations can be
challenging. The best way is not to do interoperability if you don't
have to, and find a HOWTO for those implementations if you are forced to.

IPSec isn't the only solution and may not be the best, and I suspect
freeSWAN suffered because it is relatively easy to build a simple VPN on
top of OpenSSH for example.

If all you want a VPN between these boxes is to secure data between one
specific application, such as for database synchronisation, OpenSSH port
forwarding is probably simpler to set up and adequate. Do be careful it
is easy to mess up with OpenSSH and create a setup where compromising
one box gets you on all the others.

www.freeswan.org (the news isn't encouraging, but I believe it is
shipped ready to roll in recent kernels).

Is it really private or just virtually private?

The point with VPNs is to protect sensitive data intransit between
networks, with encryption (stop people reading it), and authentication
(comes from who you expect and isn't modified on route). Indeed
encryption is usually optional a lot of people are just happy to know it
is their data unaltered.

It may well be more secure than your own private circuit (if you omit to
encrypt sensitive data on that) as dedicated circuits are usually
virtual circuits at some lower network level (ATM?) these days, but if
that data wouldn't flow if the VPN didn't exist you have added more
points for the bad guys to attack.

The usual VPN's we deployed were remote user VPN's (either IPSec or
PPTP), these typically bring the remote users laptop (or home PC) onto
the corporate network (usually they allocate it a local IP from a range
rather like a DHCP range, so it looks and feels like the remote PC is
local). And so conveniently extends your network to include hosts you
have little or no control over. As such the firewall box we sold made it
very easy to apply a clear and distinct firewall policy to such
machines. Again you are bringing more, less trusted, machines to the
party, so you need to think through the security implications.

Doing the VPN should be easier than figuring out what security policy to
apply to it ;-)

Attachment: signature.asc
Description: OpenPGP digital signature


Lynx friendly