Combining Transparent Proxying with SSH Port Forwarding

[Dan Kaminsky]

Greg--

    OpenSSH has supported Dynamic Forwarding (using SOCKS to direct a 
port forward) for several years now; see the -D option.  OpenSSH 3.7 
will support SOCKS5; builds back through 2.9 support SOCKS4.   SOCKS was 
selected because it provided a well-supported, OS independent method of 
providing external control over port selection.  Sadly, good socksifiers 
are relatively unstable and rare, which is surprising given the utter 
simplicity of the protocol.

    There are intrinsic problems with running UDP payloads inside of a 
TCP stream.  We'd also need a new SSH payload type, and I don't expect 
to see that happen without a very good reason.  Provide a list of 
circumstances where UDP forwarding would be extremely useful...this 
might help.

--Dan


Greg Houlette wrote:

>I've wondered if this topic has been discussed relative to enhancing
>the current capabilities of OpenSSH.  Please forgive me if I don't
>use the exact terminology that you may be used to in describing SSH
>or Transparent Proxy operation.  I continue to learn.  Always...
>
>Here's what I mean:
>
>1) Port forwarding through SSH is generally a configuration that is
>   "port selective".  What I mean by that is there is a port selection
>   process via the localhost mapping of the SSH daemon on the local
>   server and the SSH client on the remote system (the ports need NOT
>   be the same) and a "shared" localhost mapping of the SSH client and
>   any configured client programs on the remote system (the ports MUST
>   be the same).  The remote client programs must be configured to use
>   the "shared" localhost mapping of tunneled ports.  Once configured,
>   the selected port traffic of these client programs is then forwarded
>   through the SSH tunnel 'by proxy'.
>
>2) Transparent proxying (as I understand it) eliminates the requirement
>   to formally configure client programs (some of which may be server
>   daemons) to explicitly send their traffic to a proxy service (local
>   or remote).  This is accomplished through a mechanism of redirection
>   of traffic (the specificity of which is under considerable control).
>   By making this redirection effectively invisible and under specific
>   control, the COMPATABILITY of the application of the proxying of
>   traffic of the client programs (some of which may be server daemons)
>   is considerably increased.  It can also allows enabling and disabling
>   of the proxying on a process by process basis (specificity) on such
>   criteria as performance impact and security requirements.
>
>3) Combining Transparent Proxying with Port Forwarding using the SSH
>   protocol would entail the addition of traffic redirection capability
>   first to the SSH client, but additionally to the SSH server daemon.
>   The tunneling selection criteria would then no longer be bound just
>   to "port selection" (which any client program can access via the
>   localhost mapping) as is currently defined.  Additionally, using the
>   transparent proxying to perform protocol conversion would allow for
>   the tunneling of other IP traffic such as UDP to be performed.  And
>   it should be possible, if the capability for supporting multiple
>   SSH sessions were build into the transparent proxy for the SSH
>   client, to do more advanced and dynamic redirection of tunneled
>   traffic such as load balancing, process by process tunnel mapping,
>   and redundant reliability improvements via failover switching of
>   tunnels.
>
>I've believed for some time that the SSH capability could be enhanced
>considerably by combining it with other traffic control capabilities.
>
>Not a simple undertaking though...
>
>GregH
>
>All direct responses should use the following e-mail address rather
>than the one in the from: header (which will get you NOWHERE).
>
>
>-------------------------------------------------------------------------
>Greg Houlette <tamaster at pobox dot com>    *  Give me the graphical UI
>Do you know who owns your network today?     *  that will "condense fact
>GPG 1.2.2 Public Keys available upon request *  from the vapor of nuance"
>
>
>_______________________________________________
>openssh-unix-dev mailing list
>openssh-unix-dev at mindrot.org
>http://www.mindrot.org/mailman/listinfo/openssh-unix-dev
>  
>