remote/reverse port forward, ssh client setting source IPs to whatssh server reports

Note: most of this post is based on OpenSSH

When I do a remote forward (port on server listens for incoming
traffic, traffic gets forwarded to port that is listening on client),
the source IPs of all the incoming connections in the server app on
the client machine are 127.0.0.1/localhost. Using "-v", I can see that
sshd passes the IP addresses of what computers connected to the sshd's
port that forwards to the client. The client does not use/set the
originating information when connect. RFC 4254 requires the server
send the originating IP across the wire to the client.
-------------------------------------------------------------------------------------------------------------------------
7.2. TCP/IP Forwarding Channels


When a connection comes to a port for which remote forwarding has
been requested, a channel is opened to forward the port to the
other
side.

byte SSH_MSG_CHANNEL_OPEN
string "forwarded-tcpip"
uint32 sender channel
uint32 initial window size
uint32 maximum packet size
string address that was connected
uint32 port that was connected
###string originator IP
address###########################################
uint32 originator port
--------------------------------------------------------------------------------------------------------------------------
The 'originator IP address' is the numeric IP address of the
machine
from where the connection request originates, and the 'originator
port' is the port on the host from where the connection originated.
--------------------------------------------------------------------------------------------------------------------------

from -v of ssh, ssh client does know the originator IP and port, but
server app on computer with ssh client will never see this

--------------------------------------------------------------------------------------------------------------------------
debug1: client_input_channel_open: ctype forwarded-tcpip rchan 6 win
131072 max 32768
debug1: client_request_forwarded_tcpip: listen localhost port 80,
originator 81.910.872.450 port 50454
debug1: channel 7: new [81.910.872.450]
debug1: confirm forwarded-tcpip
debug1: channel 7: connected
debug1: channel 7: free: 81.910.872.450, nchannels 11
--------------------------------------------------------------------------------------------------------------------------


The fact that all incoming connection to the server app running on the
client are 127.0.0.1/localhost causes severe problems. Any security
scheme relying on looking at the IPs of the incoming connections to
the server app are now useless. For example if the server app is a
webserver, it can't record the IPs of customers who buy something in
an online store.

My question is, are there any ssh clients, FOSS or commercial that
will set the source IP addresses to what the ssh server reports?
Either through being a VPN, emulating a NIC/network interface, or
playing with raw sockets/socket options, or something else? For the
FOSS community, this is kindda a feature request.

I also dug around in the source of OpenSSH, "connect_to" function in
channels.c is what I think creates the connection on the ssh client to
the destination in a remote forward. It uses Berkeley Sockets. Perhaps
there should be a option to use raw sockets and spoof the source IP to
what the ssh server passed to the ssh client, or set
"ip_nonlocal_bind" with sysctl on linux or do whatever it takes to
have a arbitrary IP address bind with a particular OS (not portable, I
know), and then do a bind with the source IP form the ssh server on
the socket before doing the connect. Then OpenSSH client will be
reporting the correct source IP to the server app. Note, adding the
feature to "connect_to" would also require editing
"channel_connect_by_listen_address" function in channels.c to forward
the originating IP I think.I am not a expert an programing or posix
OSes so my implementation theories might be faulty.

I'm sure it will be asked, "why not use real layer 2 or 3 VPN
software?". I'm dealing with a grandfathered network router/firewall
that is a PC that runs FreeBSD. It can't be formated or removed and
root can not be obtained since the it belongs to the ISP/Service
Integrator/IT support company and doing any of that violates the
contract, but I am allowed legitimately to access the shell for
dealing with logs and use their configuration scripts. The server came
installed with with OpenSSH on it, I didn't install it, no limits were
put on me running any existing tool that my account has permissions to
run. OpenSSH would be the only way to run a server and meet demands
from users to run non HTTP traffic over that internet connection (box
allows web browsing through a HTTP proxy on it (no HTTPS) and for
direct TCPIP connections only some intranet software ports to hard
coded static IPs). The Service Integrator/IT support company argues
that they won't allow anything else because our support contract
doesn't cover supporting anything else, getting the support contract
changed is impossible. OpenSSH is a contract friendly way around the
problem and the only way I can think of.

On 26 Feb, 18:18, bul...@hotmail.com wrote:
> Note: most of this post is based on OpenSSH
>
> When I do a remote forward (port on server listens for incoming
> traffic, traffic gets forwarded to port that is listening on client),
> the source IPs of all the incoming connections in the server app on
> the client machine are 127.0.0.1/localhost. Using "-v", I can see that
> sshd passes the IP addresses of what computers connected to the sshd's
> port that forwards to the client. The client does not use/set the
> originating information when connect. RFC 4254 requires the server
> send the originating IP across the wire to the client.

??? I'm looking through the RFC at http://www.ietf.org/rfc/rfc4254.txt,
and I've got to tell you, I do not see what you seem to see. If the
SSH connection does *NOT* use use the SSH server's own IP address, or
one of the addresses requested by the SSH client, I don't see how any
other network services could reach back through the port. The
"originating IP address" is useless to any other services which may
connect to that local port.

Or do I misunderstand your point?