Easy VPNs?

[Dave Howe]

Ian Grigg wrote:
> I'm curious - my understanding of a VPN was that
> it set up a network that all applications could
> transparently communicate over.
spot on.

> Port forwarding appears not to be that, in
> practice each application has to be reconfigured
> to talk to the appropriate port, or, each port
> has to be forwarded.
also correct

> Am I missing something here?  If there is an
> easy SSH based strategy for VPNs, what is it?
what you are missing is joining the dots. the VPN part requires that a
server process be running that "intercepts" packets destined for the
remote end of the VPN (usually a virtual network card or ip stack shim).
That says nothing about how the data gets from *that* intercept server to
the matching server at the receiving end - the transport method.
IPSec uses an assortment of custom ip types and standard tcp/udp
connections. "ssl" vpn uses an ssl encrypted tcp/ip connection, but there
is no reason why the two intercept servers couldn't talk to each other
over (for example) a ssh tunnel, zebedee, or whatever else takes its
author's fancy.
In practice, you want the tunnel to have low overhead, so udp is often
used; tcp however traverses nat and pat servers much more easily and the
additional convenience of ssh transport (being an existing, established
standard that uses only a single port and that firewalls - and their
admins - are already familiar with) may be of more value than the more
complex and less well understood (and damned hard to get though anything,
including firewalls) IPSec.

so as I say - think of vpn as two components - intercept (the virtual
network functionality) and transport (a secure, authenticated,
encapsulated communications standard) and how vpn over *anything* becomes
more clear.

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com