Przekierowanie portu ssh nie działa w sieci firmowej

Wykonuję przekierowanie portu zwrotnego ssh, aby uzyskać dostęp za pośrednictwem publicznego IP do serwera WWW dostępnego tylko lokalnie.

Po wykonaniu tego polecenia na moim laptopie:

ssh -v -o "ExitOnForwardFailure yes" -o GatewayPorts=yes -g username@remoteserver -R '*:9080:localhost:3000' 

kiedy odwiedzę moją przeglądarkę http://remoteserver:9080, Widzę zawartość obsługiwaną przez dowolny serwer działający na localhost (mój laptop) na porcie 3000.

Działa to zgodnie z oczekiwaniami, gdy jest wykonywany na moim laptopie w domu lub podłączony do Internetu za pośrednictwem mojego iPhone'a (połączenie 3G z tethered).

To nie działa, jeśli jestem za siecią korporacyjną firmy, dla której aktualnie pracuję:

• Polecenia ssh łączą się pomyślnie, a nawet mówią All remote forwarding requests processed (patrz dzienniki poniżej)
• ale: zwiedzanie http://remoteserver:9080 od klienta w sieci firmowej po prostu pokaż „nie można połączyć błędu”
• oraz: serwer internetowy działający na laptopie na porcie 3000 nie otrzymuje żadnego połączenia

Aktualizacja: Dzięki komentarzowi Paula odkryłem, że się łączę http://remote server:9080 z klientem spoza sieci korporacyjnej działa.

Dlaczego (gdzie?) Miałby związek sieć korporacyjna - & gt; zdalny serwer - & gt; laptop w sieci lokalnej [przez ssh] być zablokowanym?

Próbowałem edytować koniec polecenia, aby przeczytać w ten sposób:

… -R '*:9080:local_ip_address_of_my_laptop:3000'

ale nic nie zmienia.

Dlaczego to nie działa?
Jak mogę to naprawić?

W poniższych dziennikach widzę jeden wiersz, który nie wiem, co to znaczy i nie mógł znaleźć przyczyny / znaczenia: debug1: Roaming not allowed by server

OpenSSH_6.2p2, OSSLShim 0.9.8r 8 Dec 2011
debug1: Reading configuration data /etc/ssh_config
debug1: /etc/ssh_config line 20: Applying options for *
debug1: Connecting to remoteserver [IP_ADDRESS] port 22.
debug1: Connection established.
debug1: identity file redacted type 2
debug1: identity file redacted type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.2
debug1: Remote protocol version 2.0, remote software version OpenSSH_4.3p2 Debian-9etch3
debug1: match: OpenSSH_4.3p2 Debian-9etch3 pat OpenSSH_4*
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Server host key: RSA redacted
debug1: Host 'remoteserver' is known and matches the RSA host key.
debug1: Found key in /Users/redacted/.ssh/known_hosts:17
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Offering DSA public key: redacted
debug1: Server accepts key: pkalg ssh-dss blen 434
debug1: Authentication succeeded (publickey).
Authenticated to remoteserver ([ip_address]:22).
debug1: Remote connections from *:9080 forwarded to local address localhost:3000
debug1: channel 0: new [client-session]
debug1: Entering interactive session.
debug1: remote forward success for: listen 9080, connect localhost:3000
debug1: All remote forwarding requests processed
debug1: Sending environment.
debug1: Sending env LC_CTYPE = UTF-8
debug1: Sending env LANG = 
debug1: Sending env LC_ALL = fr_FR

Zwykle powodem, dla którego połączenia wychodzące nie działają z sieci firmowej, jest to, że zapora blokuje sesję, a nie sam problem z ssh.

Jeśli możesz uzyskać dostęp przez port 22, możesz być w stanie wykonać lokalny port do przodu, a nie odwrotnie, w zależności od tego, co próbujesz osiągnąć.