We've the following setup:

1.a ---+
+---nat.a---Internet---nat.b---1.b
2.a----+

* nat.a and nat.b are NAT routers.

* nat.a:2222 is forwarded to 1.a:22

* nat.a is a machine with SSH access.

Our goal: We want to access 1.b from 2.a with the of reverse port
forwarding.

What I tried:

Method A: On 1.b, I ran the following command (names were, of course,
different):

ssh -R3333:localhost:22 nat.a

Now, I can connect from 2.a to 1.b as follows:

ssh -p3333 some_user@nat.a

Method B: On 1.b, I ran the following command:

ssh -p2222 -R3333:localhost:22 nat.a

Now, I tried connecting from 2.a to 1.b as follows:

ssh -p3333 some_user@1.a

This, however, failed:

ssh: connect to host 2.a port 3333: Connection refused

However, what works is connecting from 1.a to 1.b by issuing the
following command on 1.a:

ssh -p3333 some_user@localhost

Note that there is *no* firewall active on 1.a.

Any idea why method B for accessing 1.b from 2.a may be failing? It'd be
our preferred method since 1.b:22 would then not be accessible from the
Internet.

I must be missing something obvious. So far, I didn't find anything
interesting in the logs.

--
Felix E. Klee

Felix E. Klee wrote:
> Method B: On 1.b, I ran the following command:
>
> ssh -p2222 -R3333:localhost:22 nat.a
>
> Now, I tried connecting from 2.a to 1.b as follows:
>
> ssh -p3333 some_user@1.a
>
> This, however, failed:
>
> ssh: connect to host 2.a port 3333: Connection refused

port 3333 is not open on the interface you connect to.

> However, what works is connecting from 1.a to 1.b by issuing the
> following command on 1.a:
>
> ssh -p3333 some_user@localhost

[cut]

> Any idea why method B for accessing 1.b from 2.a may be failing?

Because you open port 3333 only on the loopback interface of 1.a.

Which OS/ssh-server is on 1.a ?

You should try to use the "-g"-option when connecting from 1.b to 1.a
(via nat.a):
ssh -p2222 -R3333:localhost:22 nat.a -g

Best regards,
Armin

In article <pan.2006.11.02.14.40.10.844643@liburg.de> "Felix E. Klee"
<fk@liburg.de> writes:

>We've the following setup:

[incredibly complex description snipped:-)]

>Any idea why method B for accessing 1.b from 2.a may be failing?

From 'man sshd_config':

GatewayPorts
Specifies whether remote hosts are allowed to connect to ports
forwarded for the client. By default, sshd binds remote port
forwardings to the loopback address. This prevents other remote
hosts from connecting to forwarded ports. GatewayPorts can be
used to specify that sshd should bind remote port forwardings to
the wildcard address, thus allowing remote hosts to connect to
forwarded ports. The argument must be ``yes'' or ``no''. The
default is ``no''.

It seems this has been changed from the default to 'yes' on nat.a but
not on 1.a.

> It'd be
>our preferred method since 1.b:22 would then not be accessible from the
>Internet.

I assume you mean "nat.a:22" (confusing with all those made-up names,
isn't it?:-). With both methods, 1.b:22 need to be accessible only from
localhost.

>I must be missing something obvious. So far, I didn't find anything
>interesting in the logs.

Since it's a TCP/IP level rejection (i.e. an attempt to connect to an
address:port where nothing is listening), sshd isn't even aware of it.

--Per Hedeland
per@hedeland.org

In article <1162502329.093439.321250@h54g2000cwb.googlegroups .com>
"hasenhei" <hasenhei@gmail.com> writes:
>Felix E. Klee wrote:
>> Method B: On 1.b, I ran the following command:
>>
>> ssh -p2222 -R3333:localhost:22 nat.a
>>[cut]
>[cut]
>
>> Any idea why method B for accessing 1.b from 2.a may be failing?
>
>Because you open port 3333 only on the loopback interface of 1.a.
>
>Which OS/ssh-server is on 1.a ?
>
>You should try to use the "-g"-option when connecting from 1.b to 1.a
>(via nat.a):
>ssh -p2222 -R3333:localhost:22 nat.a -g

No, this doesn't , -g only affects "forward forwarding" - the client
can't tell the server how to bind for a reverse forwarding, which makes
a whole lot of sense.

--Per Hedeland
per@hedeland.org

Per Hedeland wrote:
> In article <1162502329.093439.321250@h54g2000cwb.googlegroups .com>
> "hasenhei" <hasenhei@gmail.com> writes:

> >You should try to use the "-g"-option when connecting from 1.b to 1.a
> >(via nat.a):
> >ssh -p2222 -R3333:localhost:22 nat.a -g
>
> No, this doesn't , -g only affects "forward forwarding"

I agree here,

- the client
> can't tell the server how to bind for a reverse forwarding, which makes
> a whole lot of sense.

but not here:

from man ssh:
-R [bind_address:]port:host:hostport
[cut]
By default, the listening socket on the server will be
bound to the loopback interface only. This may be overriden by
specifying a bind_address. An empty bind_address, or the address `*',
indicates that the remote socket
should listen on all interfaces. Specifying a remote
bind_address will only succeed if the server's GatewayPorts option is
enabled (see sshd_config(5)).

So, I'd say

ssh -p2222 -R :3333:localhost:22 nat.a

should do, if 1.a has GatewayPorts enabled.

(Otherwise clients need to open another tunnel on 1.a, who cares ?)

Best regards,
Armin

In article <1162509082.126677.80680@h54g2000cwb.googlegroups. com>
"hasenhei" <hasenhei@gmail.com> writes:
>Per Hedeland wrote:
>> In article <1162502329.093439.321250@h54g2000cwb.googlegroups .com>
>> "hasenhei" <hasenhei@gmail.com> writes:
>
>> >You should try to use the "-g"-option when connecting from 1.b to 1.a
>> >(via nat.a):
>> >ssh -p2222 -R3333:localhost:22 nat.a -g
>>
>> No, this doesn't , -g only affects "forward forwarding"
>
>I agree here,
>
> - the client
>> can't tell the server how to bind for a reverse forwarding, which makes
>> a whole lot of sense.
>
>but not here:
>
>from man ssh:
>-R [bind_address:]port:host:hostport

That isn't in the man page of the version I'm running (OpenSSH 4.2p1),
but I see it is in 4.4p1.

>[cut]
> By default, the listening socket on the server will be
>bound to the loopback interface only. This may be overriden by
>specifying a bind_address. An empty bind_address, or the address `*',
>indicates that the remote socket
> should listen on all interfaces. Specifying a remote
>bind_address will only succeed if the server's GatewayPorts option is
>enabled (see sshd_config(5)).

Hm, according to sshd_config(5) in OpenSSH 4.4p1, GatewayPorts has to be
not just "enabled", but set to ``clientspecified'' for this to work.
(I.e. it's still the case that the server decides, as it should be, just
that it may decide to let the client decide.:-) If set to ``yes'', sshd
should unconditionally bind to the wildcard address, and the OP's
problem wouldn't occur in the first place. Of course my 4.2p1
sshd_config(5) has only the yes/no settings - the OP didn't state what
version he was running.

--Per Hedeland
per@hedeland.org

On Fri, 03 Nov 2006 00:19:08 +0000, Per Hedeland wrote:
> If set to ``yes'', sshd should unconditionally bind to the
> wildcard address, and the OP's problem wouldn't occur in the
> first place.

That works - thanks!

> sshd_config(5) has only the yes/no settings - the OP didn't state what
> version he was running.

Version 3.9.

--
Felix E. Klee

On Thu, 02 Nov 2006 21:25:51 +0000, Per Hedeland wrote:
> I assume you mean "nat.a:22" (confusing with all those made-up names,
> isn't it?:-). With both methods, 1.b:22 need to be accessible only from
> localhost.

No, I do mean 1.b:22. The reason that it is accessible from anywhere via
nat.a:3333 (method A) is: On nat.a, sshd 1.2 is running and - as I just
learned - this version does have "GatewayPorts" enabled all the time.

--
Felix E. Klee