Troubleshooting Local Port Forwarding in SecureCRT

[jdev]

The suggested steps for troubleshooting local port forwarding issues in SecureCRT are, in summary:

1. Turn on Trace Options from SecureCRT's main File menu and establish your connection to the SSH2 server.
2. Look for evidence in the Trace Options output indicating the ability/inability to open the local listening socket:port.
3. Connect with the TCP client to the local port forward socket.
4. Look for evidence in the Trace Options output of problems either setting up the port forwarding channel or reaching the end host.

To explain in more detail, we effectively are seeking answers to the following questions:

1. Was SecureCRT able to successfully connect and authenticate to the SSH server?
   SecureCRT will not even try to open any local listening ports if it's not able to successfully connect and authenticate to the SSH2 server. See #1 and #2 in the graphic below.
   
   
2. Was SecureCRT able to successfully start listening on the local address:port specified?
   Once authenticated to the SSH2 server, then SecureCRT will make a request of the OS to open a listening socket/port. See #2 in the graphic below.
   
   What errors are reported by the OS to SecureCRT following successful authentication?
   
   Such errors are visible mostly through Trace Options debug logging in SecureCRT. Here's an example of macOS saying, effectively, "You gave me a bad address:port that I cannot possibly listen on, sorry!"

   [LOCAL] : RECV : AUTH_SUCCESS
   [LOCAL] : Unable to setup port forwarding for local address 127.8.8.8:8888. Can't assign requested address
   [LOCAL] : SEND[0]: SSH_MSG_CHANNEL_OPEN('session')
   [LOCAL] : SEND[0]: Pty Request (rows: 42, cols: 80)
   [LOCAL] : RECV[0]: pty request succeeded
   [LOCAL] : SEND[0]: shell request
   [LOCAL] : RECV[0]: shell request succeeded

   If you don't see any errors in Trace Options output between the AUTH_SUCCESS and the SSH_MSG_CHANNEL_OPEN('session'), then it's likely that the request made to the OS to open a listening port was successful.
   
   One typically can use the following command in a local shell to verify what's LISTENING:

   Linux:
   netstat -an | grep tcp | grep LISTEN | grep ":"
   
   macOS:
   lsof -nP -i TCP -sTCP:LISTEN
   
   Windows (CMD shell):
   netstat -an | findstr "LISTEN" | findstr "TCP"
   

   For example on my macOS:
   

   mymachine:~ me$ lsof -nP -i TCP -sTCP:LISTEN
   COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
   SecureCRT 93886 me 32u IPv4 0x6fa202b1b5f90285 0t0 TCP 127.0.0.1:8888 (LISTEN)
   mymachine:~ me$

   
   
3. When the TCP client connected to the local listening address:port, was there any error reported by SecureCRT when it requested of the SSH server that a forwarding channel be created? (See #3 in the graphic below)
   Such info is available via Trace Options output. For example, the following trace options output sample indicates that the SSH2 server does not allow/support port forwarding:

   [LOCAL] : Starting port forward from 127.0.0.1 on local 127.8.8.8:8899 to remote 127.0.0.1:2222.
   [LOCAL] : Could not start port forwarding from local service 127.0.0.1:49962 to 127.0.0.1:2222. Reason: Opening the channel was administratively prohibited. Server error details: 00002: Port forward access denied

   
   
4. When the forwarding channel was created, did the SSH2 server report any errors reaching the specified TCP destination:port on the other side? (See #4 in the graphic below)
   Again, such info is available via Trace Options output. For example, the following trace options output sample indicates that the SSH2 server received the forward request successfully, but was unable to establish a connection to the remote service:port (either nothing was listening on port 2221, a firewall blocked it, or the service listening on port 2221 refused the connection attempt):

   [LOCAL] : Starting port forward from 127.0.0.1 on local 127.8.8.8:8899 to remote 127.0.0.1:2221.
   [LOCAL] : Could not start port forwarding from local service 127.0.0.1:49999 to 127.0.0.1:2221. Reason: The channel could not be opened because the connection failed. Server error details: 00002: Port forwarding connection to 127.0.0.1:2221 failed. Error: Connection refused

Here's a graphical representation of local port forwarding components and sequencing:

Notes:

• The Client-side TCP Application doesn't always need to be running on the same machine as SecureCRT. It's simply depicted as being on the same machine in the graphic above for the sake of simplicity.
  By default, however, SecureCRT will reject any incoming connections on its local port forward listening port where the source IP of the client TCP connection do not match the pattern 127.*.
  Though it's not a security best practice, you can open up SecureCRT's 'Port Forward Filter' to allow other IP addresses and hosts to connect to your forwarded port.
  For more information, visit SecureCRT's built-in Help -- specifically the topic "Configuring Port-Forwarding Filters"
  
  
• The Server-side Remote TCP Service doesn't always need to be running on the same machine as the SSH2 server. It's simply depicted as being on the same machine in the graphic above for the sake of simplicity.

--Jake