View Single Post
Old 03-06-2012, 12:08 PM
jdev's Avatar
jdev jdev is offline
VanDyke Technical Support
Join Date: Nov 2003
Location: Albuquerque, NM
Posts: 1,099
The log information indicates that the VRALib connection is not able to reach the target machine with an initial TCP/IP connection (the connection is closing even before the server's SSH Ident string shows up, so authentication isn't even a factor yet).
  • Check firewall/proxy rules on the client side to ensure that your .NET exe (the one that's using VRALib) is allowed to make outgoing TCP connections.
  • If by chance you're connecting with your VRALib app from a machine that's different from the machine on which SFXCL is running, you might also consider that something (a firewall rule or connection filter) on the remote side may be disallowing the initial connection if it's coming from a different IP address than expected.
  • If SFXCL is running on the same machine successfully where the VRALib app is running unsuccessfully, then you might check still for a personal firewall that blocks all apps that are not specifically and explicitly allowed to make outgoing connections.
  • Something else that comes to mind is that if SFXCL is using the 'sftp://user:pass@host' URL command line construct, it's getting configuration settings (such as Proxy/Firewall settings) from the "Default" session as defined in the SecureFX application. VRALib is a separate, distinct entity, and does not know about any SecureFX configuration settings. If you have SecureFX's "Default" session configured to connect through a proxy/firewall, you'll need to try and duplicate the same proxy connection configuration in VRALib by setting the appropriate Firewall_________ properties (FirewallHostname, FirewallPort, FirewallType, FirewallUsername (if needed), and FirewallPassword(if needed)) of the VRALib Connection object in your code before you call Connect().
  • One other thing. You're setting DebugLevel = 99, which is excessive. DebugLevel values greater than 9 will expose passwords in the log file, which you may not want to do unless you're trying to debug packet-level data; additional details aren't logged beyond a value of 15 or so, depending on the version you're using. Choosing a debug level of 1 is sufficient to troubleshoot most connection problems.

For example:
            objConn.DebugLevel = 1;
            objConn.Hostname = @"";
            objConn.Port = 22;
            objConn.FirewallHostname = @"";
            objConn.FirewallPort = 1080;
            objConn.FirewallType = @"socks5";            
            objConn.Username = @"user";
Jake Devenport
VanDyke Software
Technical Support
YouTube Channel:
Reply With Quote