I'm doing ssh reverse port forwarding to access via a public ip a web server only accessible in local.

After executing this command on my laptop:

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

when I then visit in my browser http://remoteserver:9080, I see the content served by whatever server is running on localhost (my laptop) at port 3000.

This works as expected when done on my laptop at home, or connected to internet via my iPhone (tethered 3G connection).

It doesn't work if I'm behind the corporate network of the company I'm currently working for:

  • the ssh commands connects successfully, and even says All remote forwarding requests processed (see logs below)
  • but: visiting http://remoteserver:9080 from a client inside the corporate network just show a "can't connect error"
  • and: the web server running on the laptop at port 3000 does not receive any connection

Update: Thanks to Paul's comment, I discovered that connecting to http://remote server:9080 with a client outside the corporate network, it works.

Why (where?) would a connection from corporate network -> remote server -> laptop on local network [via ssh] be blocked?

I tried to edit the end of the command to read like this:

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

but it doesn't change anything.

Why isn't it working?
How can I fix it?

In the logs below, I see one line that I don't know what it means and couldn't find the reason/meaning: 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_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
  • What doesn't work exactly? Is the laptop inside the corporate network and able to ssh to remoteserver? And is the client connecting to remoteserver:9080 outside or inside the corporate network?
    – Paul
    Feb 11, 2014 at 10:45
  • @Paul Thank you! It works if the client connecting to remoteserver:9080 is outside the corporate network (but doesn't work if inside). Will have a chat with local sysadmin, but any idea what might cause this?
    – Guillaume
    Feb 11, 2014 at 11:02
  • Yes, they have a firewall blocking access to port 9080 - this is pretty common.
    – Paul
    Feb 11, 2014 at 11:03
  • Duh! Brain was stuck in ssh debug perspective, thanks for the reset. Will test with 80:localhost:3000 and let you know.
    – Guillaume
    Feb 11, 2014 at 11:09
  • They could also be blocking port 80 - and have web traffic going via a proxy. But yes, once you find a port that you can exit the network with, you should be good to go.
    – Paul
    Feb 11, 2014 at 11:15

1 Answer 1


The usual reason that outgoing connections aren't working from a corporate network is that a firewall is blocking the session, rather than an issue with ssh itself.

If you can get access via port 22, you may be able to do a local port forward rather than reverse, depending on what you are trying to achieve.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.