From bug 2147:

> I've been doing some more testing on this, and I think it may have
> been a mistake for me to replace the hostname in the channel open
> message with the actual listening address. By doing that, it makes it
> more difficult for the client to match up against the right listener.
>
> That said, the reason I didn't discover this in my testing is that
> the current openssh client code doesn't actually try to match on
> the hostname at all when matching which remote listener it is -- it
> only matches on port! So, if you try to set up multiple listeners
> at once from a client on the same server-side port (by setting
> GatewayPorts=clientspecified in the server config and binding to
> different addresses), the client always matches on the first listener
> with that port, as seen in the following code snippet:
>
> Channel *
> channel_connect_by_listen_address(u_short listen_port, char *ctype, char *rname)
> {
>         int i;
>
>         for (i = 0; i < num_permitted_opens; i++) {
>                 if (permitted_opens[i].host_to_connect != NULL &&
>                     port_match(permitted_opens[i].listen_port, listen_port)) {
>                         return connect_to(
>                             permitted_opens[i].host_to_connect,
>                             permitted_opens[i].port_to_connect, ctype, rname);
>                 }
>         }
>         error("WARNING: Server requests forwarding for unknown listen_port %d",
>             listen_port);
>         return NULL;
> }
>
> Note that it checks here that a host_to_connect is set, but it doesn't
> even pass in the listen_address to match against when this is called
> from client_request_forwarded_tcpip() in clientloop.c. This means
> you can't actually have two different listeners on the server side
> with the same port listening on different addresses and forwarding to
> different destinations.
>
> My suggestion is to keep the portion of my change which fills in the
> proper listening port instead of 0, but leaves the reported listening
> address as the hostname/address which was requested. That way, a
> client which does proper matching of both the listening host & port
> would always be able to do so (since it got the actual licensing
> port back in the global request's response when dynamic ports were
> requested). To make this work right with OpenSSH as a client, though,
> additional changes would be needed on the client side to extend the
> listener matching to include both the host & port.