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 [EMAIL PROTECTED]