binding source address for ssh port forwarding

The title on the question is exactly precise, but after having asked in a few other places, I find there is confusion. So a more verbose and redundantly phrased question is:

When I use ssh to forward TCP connections with either the -D option (DynamicForward) or the -L option (LocalForward), I would like to be able to specify what IP address (v4 or v6) is used as the source address when connections are made from the remote host as part of completing a connection forwarding setup. Is there any wrapper, wedge library, source code patch, or agent program that can use ssh, to accomplish this?

What exists now is the ability to bind the LISTEN address on the local host (the destination address when making a new connection), and in the case of -L (LocalForward), also the (required) ability to specify the address to be connected to. Neither of these provides a means to specify what address the connection being made from will be, so the remote host IP stack chooses an appropriate default address. The ssh command does have the -b option (BindAddress) to specify the source address of the ssh protocol connection itself (whether forwarding is being used or not). This is a good feature to have, but it is not the one I am asking about right now.

The source port might, in more rare cases, be desirable to configure, too.

The practical ways I see to do this could be:

1. A patch to the ssh package source (for both client and daemon since this would involve new data being conveyed over the ssh protocol) to add the ability, along with command/config syntax to specify it.

2. An agent program to carry out this more sophisticated forwarding itself, through an ssh client it starts up, and through the remote agent copy of itself it runs via ssh. This might also be a means to implement SCTP session forwarding, too.

Probably impractical is a library wedge. It would be more cumbersome to do this because it would be needed on the remote side and involve a more controlled startup of sshd (on a different port).

I'm looking around to see if someone has already done so. If not, and if I end up doing this, I would use method #2 above, as I'd rather not mess with the insides of ssh, which could break its security, make it incompatible with unpatched ssh, and be a perpetual maintenance headache. I might also want to include SCTP forwarding. If Theo de Raadt wanted to add this capability, method #1 might be the suitable way for him.

So is there anything out there to do this?

I have read like 3 times your post but could not find what exactly what were you talking about. You want to:

a. Control the local bind address? It's ssh <username>@<host> -L <local_ip>:<local_port>:<remote_ip>:<remote_port>
b. Set what address is delivered to the <remote_ip>? I think that is the job of iproute or iptables on your <host>

I'm declaring to lazy to read some more. So please could you summarize what you want to do?

Hi Skaperen

All these years later and I have exactly the same problem: the server that I'm ssh'ing into has many IP addresses, and I want to control which one of those appears as the source of any outbound connections that it makes on my behalf.

I'm sure part of the reason we have trouble getting people to understand our question is that people wrongly assume that a host has only one IP address. (At minimum it will have 2 - loopback and one routable address - but one host with dozens or even hundreds of addresses is possible.)

Another problem is that people muddle up 'bind' with 'listen'. 'Binding' is required when creating a listening socket, but optional when creating an outbound connection, and also quite rare in that case.

For the benefit of ndarkduck and anyone else who fails to see the picture, please consider there are several ways to connect
Host A (my device) → Host B (proxy) → Host C (eventual target)

A true VPN encapsulates the IP layer, allowing a single TCP connection to reach from host A to host C, so that host C will see an IP address on host A as the source of the incoming connection. (That address will always be the one assigned to the virtual VPN interface on A; and almost always that address will have been assigned to it by the tunnel server on B.)

SSH and SOCKS tunnels on the other hand involve two separate TCP connections: one from host A to host B, and another from host B to host C. Host C will see an IP address on host B as the source of the incoming connection.

Skaparen and I both want to control how the IP address on host B is selected, because sometimes host C is fussy about who it will accept connections from.

or host C sees the VPN's translation of host A's address.

i've done this where LAN A and LAN C are numbered the same. the workaround for so many IP collisions was that each LAN (i was doing this for about 20 of them, a VPC in every AWS region, all with default numbering) was to make each LAN appear to have a new unique CIDR translating both ways to complete this. it was all done statically, a whole /16 LAN at a time.

wow, that is an old thread you found. i no longer work where i needed to do that (retired).