How Secure Shell Tunneling Works

When the LAN cannot be trusted or intranet servers are at a premium, VShell® can run on the same machine as the server application (see Figure 3). In this case, there is no need to specify a remote host in the port forward - SecureCRT® and VShell interact with client/server applications on each local host. Application packets are protected end-to-end; cleartext is never sent over the network.

Figure 3: Local Port Forwarding to Application on VShell Server

Local port forwarding is appropriate when SecureCRT is running on the same PC as the client application, initiating outbound TCP connections to the server application. Occasionally, users need to accept TCP connections initiated in the reverse direction by an application on the Secure Shell server-side. This can be accomplished with remote port forwarding, described in Appendix A.

These examples illustrate the broad power and flexibility of Secure Shell tunneling. But it is also important to bear in mind:

• Secure Shell forwards individual TCP connections, but not port ranges. Multi-connection applications like FTP that use ephemeral ports do not lend themselves well to port forwarding. To transfer files securely over Secure Shell, it is better to use SFTP or SCP protocols, supported by VanDyke VShell server, SecureFX® file transfer client, and the VCP command-line utility.
• Although conceptually possible, standard Secure Shell does not forward UDP datagram services. However, RPC-based UDP protocols like NFS can be tunneled over Secure Shell using freely-available extensions like SNFS.