VPN solution(s) for Fedora Core

[James Yonan]

Felipe Alfaro Solana <felipe_alfaro at linuxmail.org> said:

> On Fri, 2004-05-21 at 17:52, Jason Tackaberry wrote:
> 
> > There seem to be two general approaches to VPNs, each with their own
> > advantages and disadvantages: kernel space, and user space.  I feel the
> > only kernel solutions worth considering are those which implement IPsec.
> > There exist several packages implementing VPN solutions in userspace,
> > such as vtun, tinc, and OpenVPN.
> 
> I would stick with industry-standard technologies, like IPSec, as much
> as possible. I have used IPSec in tunnel mode to setup VPN tunnels
> between several branch offices.

While IPSec tends to work fine for static VPNs in cases where you have full
control over all firewalls, there are cases that come up where IPSec cannot be
used, such as

* Mobile (i.e. road-warrior) usage.  Road warriors running a VPN client on a
laptop may need to securely connect from untrusted networks such as client
sites, internet cafes, LANs behind NAT, etc., where the VPN user does not have
control over the firewall policy on the local network.  A user-space VPN such
as OpenVPN can connect via TCP, UDP, HTTP, socks, etc, and can do it over NAT.

* VPNs between machines which don't have a static IP address, such as cable
modem or DSL clients which have a DHCP assigned address.  OpenVPN has the
ability to "follow" its peer if it changes its address due to a DHCP reassignment.

* IPSec is tightly coupled with IP and therefore is principally suited for
securing IP-based routed networks.  However an extremely common VPN
application is in securing ethernet 202.3 bridges.  User space VPNs which
utilize TUN or TAP type virtual network interfaces can tunnel or bridge
arbitrary application or transport protocols transparently.

As far as the issue of industry standarization is concerned, there is not yet
an RFC to standardize SSL/TLS VPN usage.  This is certainly a valid issue,
though movement is occuring toward drafting a standard.  A key point to
recognize is that even though SSL/TLS VPN protocols have not been canonized by
RFC, the security technologies being utilized HAVE been.  OpenVPN for example
uses SSL/TLS for authentication and key exchange, and IPSec's ESP for datagram
security.

The other issue concerning standardization is that VPNs with extreme
cross-platform portability have less of a need for multi-vendor
interoperability simply because they can be run on almost any platform.

James