[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: VPN solution(s) for Fedora Core



On Fri, 2004-05-21 at 22:32, James Yonan wrote:
> > 
> > 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.

I think this can/will be solved by implementing Mobile IPv4 or Mobile
IPv6 and using Home Agents that are able to proxy the mobile host and
thus masquerade the fact that it has changed its network attachment and,
with high probability, its IP address. In fact, I think there are Mobile
IPSec extensions currently in draft status.

However, it's probably more difficult to implement a solution based on
Mobile IPSec at the moment than using a solution like OpenVPN.

> * 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.

I think the previous paragraph still applies here.

> * 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.

I agree.

> 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.

There are several drafts related to VPN technologies, like MPLS VPNs,
IPSec + L2TP for end-user and machine authentication, and SSL/TLS/SSH
tunneling. They will take time to reach the standard status, but I think
this will happen sooner or later.



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]