openssh unix dev - Sep 2003 - Combining Transparent Proxying with SSH Port Forwarding

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"

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

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...
There are patches around to use OpenSSH dynamic portforwarding as a 
transparent gateway under OpenBSD pf's NAT. I don't know whether we want
to support and maintain variants for every OS's favourite packet filter 
in the tree though...

-d

Thanks for the feedback.  I still have a few questions of course...

The Dynamic Forwarding that is currently in OpenSSH (-D option)
which uses the SOCKS protocol, still requires an application-level
'socksifier' to provide transparency on the client side, but lacks
other features of a traditional transparent proxy (such as NAT)?

I haven't seen or used any of the patches that Damien mentioned, and
I can understand why, for the sake of utility, it would be preferable
to keep this kind of feature as a seperate connector module.

I just don't have a feel for how much bloat a transparent NAT -> SSH
proxy capability would add, but I suspect that once in place it might
get to be pretty sizable as more advanced features were added.

The idea of a standalone transparent NAT -> SOCKS gateway daemon
is something that I haven't seen, let alone with the other features
that I mentioned in my post.  That does seem like a good starting
point though.  And I like the independent utility aspect of it.

I wish Markus would elaborate about what he's using?

GregH

    ||||||||        ||||||||        ||||||||       ||||||||
    vvvvvvvv        vvvvvvvv        vvvvvvvv       vvvvvvvv
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"