Welcome to the VanDyke Software Forums

Join the discussion today!


Go Back   VanDyke Software Forums > General

Reply
 
Thread Tools Display Modes
  #1  
Old 05-19-2011, 03:33 AM
rleyba rleyba is offline
Registered User
 
Join Date: Feb 2010
Posts: 24
Is it possible to do reverse tunneling in Securecrt?

Hi Team,

Just wanted to know if there are tips or documentation in securecrt (I am using ver 6.5.1) that will allow reverse tunneling?

My scenario is that I have a set of LAB Linux servers where I can ssh to the LAB devices through a firewall but the LAB servers cannot connect to the main office network....so connectivity is inbound only into the LAB.

In some situations, the Linux machines inside the LAB need to connect to the internet via a proxy server in order to do software updates.

Is it possible to ssh to these devices (from my main office network) and do some kind of reverse port forwarding so that if I configure the LAB PC with a proxy server setting of 127.0.0.1:8080, then it will tunnel back to the machine that initiated the connection and thus allow it to access the external proxy server?

Thanks very much.



http://forums.vandyke.com/search.php?searchid=311372
Reply With Quote
  #2  
Old 05-19-2011, 10:59 AM
gregg gregg is offline
Registered User
 
Join Date: Oct 2010
Posts: 53
Thumbs up

I'm also interested in reverse tunneling. Right now I'm having to use another product (on Windows XP) to do this.

(it's called tunnelier)
Reply With Quote
  #3  
Old 05-19-2011, 11:15 AM
bgagnon bgagnon is offline
VanDyke Technical Support
 
Join Date: Oct 2008
Posts: 4,309
Hello rleyba,

There is a way this will work.

Pre-conditions
Machine on which SecureCRT is installed must have access to a web proxy.
SSH server must support remote port forwarding.

For the sake of this example we will say the web proxy IP address is 192.168.0.1.

Remote Port Forwarding properties (see attached)
Remote
IP address: 127.0.0.1
Port: 8080

Local
Hostname: 192.168.0.1
Port: 8080
Attached Images
File Type: gif remote_port_forward_example.gif (15.1 KB, 1430 views)
__________________
Thanks,
--Brenda

VanDyke Software
Technical Support
support@vandyke.com
(505) 332-5730

Last edited by bgagnon; 05-19-2011 at 11:22 AM.
Reply With Quote
  #4  
Old 05-19-2011, 11:20 AM
gregg gregg is offline
Registered User
 
Join Date: Oct 2010
Posts: 53
Oh, this is going to be no help to support (sorry) but for some reason I could not get Remote/X11 "Remote Port Forwarding" configuration to work and I can't remember why now (it was sometime last year when I tried that approach).

Maybe rleyba will have better luck with it. When I get a chance I'll try again and see what actually happened. It's one of those situations where I found a working solution and never revisited it, even though I use it everyday.

In my case am connecting to an openssh server (i'm pretty sure) on a debian system and sending RDP through the tunnel.
Reply With Quote
  #5  
Old 05-19-2011, 01:29 PM
jdev's Avatar
jdev jdev is offline
VanDyke Technical Support
 
Join Date: Nov 2003
Location: Albuquerque, NM
Posts: 998
SecureCRT's port forwarding "allowances" fall on the cautious side of security. This is the case for both local and remote/reverse port fowards, which ensures security by default but also means it's not the most convenient default setting if your needs are "special".

In the case of reverse forwards, SecureCRT imposes a default filter that rejects any forwards that don't originate on the server side from the server's loopback address (127.0.0.1). This means that if the (server-side) client application sets the src addr to anything other than 127.0.0.1 (such as a non-loopback NIC address like 192.168.x.y), SecureCRT will deny such forwarding packets received, dropping packets w/o forwarding them on to the configured destination on the SecureCRT side. Such a denial can be seen in debug output if you enable Trace Options (SecureCRT's main "File" menu) prior to connecting to the remote machine.

A denial/rejection looks like this, as one example, in Trace Options debug output (displayed in the SecureCRT terminal window the moment a server-side client application attempts to access the port from a filtered src address/port):

[LOCAL] : RECV: CHANNEL_OPEN[forwarded-tcpip]
[LOCAL] : Rejecting remote forward request from 192.168.232.101:1220 to 10.0.0.1:8080 because the current filters do not allow 192.168.232.101:1220 to use the remote forward.



To relax SecureCRT's reverse forward filters to allow access for more than just localhost-originating addresses on the remote side, you'll need to manually edit the session's .ini file appropriately (make sure you close SecureCRT prior to changing a session's .ini file manually).

Here's the line in the session's .ini file that you'll need to modify:

S:"Reverse Forward Filter"=allow,127.0.0.1,0 deny,0.0.0.0/0.0.0.0,0


If you want to allow everything through (not the most secure choice, but works if you're just setting it up for a PC on a controlled LAB network), do this:

S:"Reverse Forward Filter"=allow,0.0.0.0/0.0.0.0,0


If you just want to allow everthing on the 192.168.x LAN segment, as well as any loopback adapter access to the forwarded port (denying access to all other originating addresses), do this:

S:"Reverse Forward Filter"=allow,192.168.0.1/255.255.0.0,0 allow,127.0.0.1/255.0.0.0,0 deny,0.0.0.0/0.0.0.0,0


This information is described in detail (including ipv6 how-to) within the SecureCRT help under the topic titled, "Configuring Port-Forwarding Filters" located within the "Secure Connections" top-level chapter.

--Jake
__________________
Jake Devenport
VanDyke Software
Technical Support
YouTube Channel: https://www.youtube.com/vandykesoftware
Email: support@vandyke.com
Web: https://www.vandyke.com/support
Reply With Quote
  #6  
Old 05-20-2011, 04:55 AM
rleyba rleyba is offline
Registered User
 
Join Date: Feb 2010
Posts: 24
Hi Brenda, Jake,

Thanks for this. I am a little confused now....Does the screen capture provided by Brenda work as-is, or should i do some tweaking of the ini files. I plan to mirror the settings on Brenda's jpg capture.

To answer Brenda's question, yes the machine where the securecrt is involved DOES have access to the web proxy, and the SSH server can allow remote port forwarding.

I use FreeSSHD for windows on the remote box and I ticked "Allow Remote port forwarding".

However, I still can't make the reverse tunnel work. Let me do some wireshark to see what goes on and will post some results here.

Thanks for all the help.
Reply With Quote
  #7  
Old 05-20-2011, 09:32 AM
jdev's Avatar
jdev jdev is offline
VanDyke Technical Support
 
Join Date: Nov 2003
Location: Albuquerque, NM
Posts: 998
Quote:
Originally Posted by rleyba
Does the screen capture provided by Brenda work as-is
No. You must change the settings to values that make sense for your environment. For example your Local Hostname parameter should match the hostname or IP address of the web proxy that is available to your SecureCRT client machine.


Quote:
Originally Posted by rleyba
...or should i do some tweaking of the ini files. I plan to mirror the settings on Brenda's jpg capture.
Tweaking the session's .ini file as I mentioned in an earlier post is needed if you see in SecureCRT's trace options debug output that reverse forward requests are being denied by SecureCRT.


Quote:
Originally Posted by rleyba
However, I still can't make the reverse tunnel work. Let me do some wireshark to see what goes on and will post some results here.
Here are some troubleshooting steps I'd suggest prior to doing any wireshark:
  • Make the configuration changes needed to set up reverse port forwarding using the local hostname/address of the web proxy available to your SecureCRT client-side machine.

  • Choose File / Trace Options in SecureCRT before connecting to the remote host.

  • Connect to the remote host ssh server using the configured session in SecureCRT.

  • After a successful connection is established with SecureCRT to the remote ssh server, scroll up through the trace options output in the SecureCRT terminal window and look for evidence that a reverse forwarding request was sent by SecureCRT to the SSH server, and whether it succeeded or failed.
    Success would be indicated by this pattern of trace options debug output:
    [LOCAL] : SEND : tcpip-forward request: 127.0.0.1:8080
    ...
    [LOCAL] : RECV : tcpip-forward request succeeded: 127.0.0.1:8080


    Failure would be indicated by this pattern of trace options debug output:
    [LOCAL] : SEND : tcpip-forward request: 127.0.0.1:8080
    ...
    [LOCAL] : RECV : tcpip-forward request failed: 127.0.0.1:8080


    The Success/Failure the above refers to is SecureCRT's request to the SSH server to, "Please, sir SSH Server, would you be so kind as to listen on your side for incoming connections on <address>:<port> and forward any data you receive on this address:port back to me(the client)?"

  • If the reverse forward request failed, then you'll need to inspect the SSH server's logs to determine the "why", because this information is not communicated back to the client.

  • If the reverse forward request succeeded, and you have a shell prompt, use the 'netstat' command (at the remote ssh server system prompt, of course) and confirm that there is in fact a port open and listening on the desired address:port.
  • If everything is successful up to this point, then you would run the browser client on the lab machine that has been configured to use the forwarded port as its web proxy.

    At the moment you open the web browser on the lab machine and it attempts to find a web host through the proxy, you should see some trace options debug output in SecureCRT's terminal window, indicating that SecureCRT has received a packet forward request from the port the ssh server opened up upon request from SecureCRT.

    If you don't see any trace option output at this moment, it indicates something isn't quite configured right on the client side, or there's a firewall blocking traffic from reaching the address/port you specified for the remote in SecureCRT's reverse port forwarding config.

  • If you actually do see trace options output indicating an incoming connection was forwarded on to the address:port on the local side, then that means SecureCRT is doing exactly what you instructed it to do when it receives a forward packet from the remote ssh server.

If the above doesn't help and you're still having problems determining the cause of the failure, please provide the trace options output associated with your connection attempts and other debugging information such as web browser client configuration on the remote lab machine, 'netstat' output on the remote lab ssh server machine, etc.

--Jake
__________________
Jake Devenport
VanDyke Software
Technical Support
YouTube Channel: https://www.youtube.com/vandykesoftware
Email: support@vandyke.com
Web: https://www.vandyke.com/support

Last edited by bgagnon; 04-13-2020 at 09:49 AM. Reason: Fixed typo: they to the
Reply With Quote
  #8  
Old 05-21-2011, 04:29 AM
rleyba rleyba is offline
Registered User
 
Join Date: Feb 2010
Posts: 24
Hi Jake,

Thanks for this very comprehensive how-to. I will try out your troubleshooting steps when I get to the office on Monday.
Reply With Quote
  #9  
Old 06-24-2017, 11:37 PM
vwal's Avatar
vwal vwal is offline
Registered User
 
Join Date: Aug 2009
Location: North Texas, U.S.
Posts: 7
Question

This is an old thread, but I'm looking at the same situation, six years later. I'm trying to reverse proxy port 52698 in order to use rsub. It can be done with PuTTY; I just tested it, and it works. But since I usually use SecureCRT instead of PuTTY, I'd rather have this working with it also. I tried the suggestions in this thread (using the web proxy IP instead of that of the local system, and adjusting the Reverse Forward Filter rules in the session's INI file), but thus far it's no-go.

Any thoughts how this could be accomplished it the current-version SecureCRT?

Thanks!

Last edited by vwal; 06-24-2017 at 11:40 PM.
Reply With Quote
  #10  
Old 06-26-2017, 09:44 AM
ekoranyi ekoranyi is offline
VanDyke Technical Support
 
Join Date: Jan 2017
Posts: 654
Hi vwal,

I'm sorry to hear you are having trouble. I may need additional logged information to better diagnose what's happening.

Because logs may contain sensitive data I'd ask that you take the following steps and provide the log via email. Please email Support@VanDyke.com with "Attn: Eric forum thread 7666" in the subject line.

- Launch SecureCRT and open SecureCRT's main "File" menu and select the "Trace Options" menu item.

- Open the "File" menu again and choose "Log Session..."
--> Specify a path to your Desktop folder and a name of the log file, such as SCRT_Log.txt. For example: %APPDATA%\..\..\Desktop\SCRT_Log.txt

- Now attempt your connection again.

- When the connection fails, open SecureCRT's "File" menu and look at the "Log Session" menu item. If it has a check-mark next to it, click on it to turn off logging.

- Go to your Desktop folder and locate the SCRT_Log.txt file. Please send the SCRT_Log.txt file to me as an attachment to your reply. Please don't paste the contents into the body of your message -- please attach it!

What version of SecureCRT are you using?
__________________
Thanks,
--Eric

VanDyke Software
Technical Support
support@vandyke.com
(505) 332-5730
Reply With Quote
Reply


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT -6. The time now is 06:06 PM.