SOCKS connection not allowed by ruleset.

[mr.dk]

Hello,

I'm setting up dynamic socks proxy as per "https://www.vandyke.com/support/tips/socksproxy.html

My master connection is successful. I have also tested forwarding ports manual successfully.

However when I try to connect to the detestation use the socks proxy I get this message "SOCKS connection not allowed by ruleset"


Thank you.

[bgagnon]

Hi mr.dk,

What version of SecureCRT are you using (Help / About SecureCRT...)?

What do you mean by this:

I have also tested forwarding ports manual successfully.

Are you saying when configured via the Connection / Port Forwarding category, you can successfully connect through "JumpHostB" to reach "TargetHostA"?

If so, then the message likely means the jump host does not support dynamic/SOCKs port forwarding.

[mr.dk]

I have the same error message here on version "Version 7.2.6 (x64 build 606) - Official Release - August 19, 2014"

When I wrote the message I was connecting using the latest non-bata release 8.x .

Thank you.
Derek

[mr.dk]

Version 7.2.6 (x64 build 606) - Official Release - August 19, 2014
I also have the latest non-bata 8.x version installed with the same message.


What do you mean by this:
I have also tested forwarding ports manual successfully.

On the master, if simply forward a port, and not use socks option I can connect to the forwarded port.


Thank you.

[bgagnon]

Hi Derek,

The version of SecureCRT won't matter when the jump host doesn't support dynamic port forwarding. You would probably need to talk to the admin of the jump host to see if it's something they intentionally disabled or continue using the other port forward configuration.

[mr.dk]

Originally Posted by bgagnon

The jump host doesn't support dynamic port forwarding.

Is there a message log that would provide technical details as a confirmation about the remote side not support dynamic mapping?

Is there a server side SSHD configuration parameter that must be enabled?


Thank you.
Derek

[bgagnon]

Hi Derek,

Note also, that in order to use dynamic port forwarding, the client that connects to the forwarded port on the SecureCRT side of things *must* be able to be configured with SOCKS4/5 in order to connect to the forwarded port.

Do you know if the client connecting to the forwarded port supports SOCKS?

It's often useful to see trace options output which provides debugging information that may help us better understand the problem that you're experiencing.

To enable trace options output:

• First, open SecureCRT's main File pull-down menu and select Trace Options. If you open the File pull down menu again you should see a checkmark next to Trace Options, indicating that troubleshooting output is now enabled.
  
• Next, connect to the remote machine. With trace options enabled, you will notice debugging information displayed in the terminal window that isn't normally there by default when SecureCRT is attempting to establish a connection, and at certain times throughout the lifetime of the connection.
  
• Once the problem occurs, please right-click inside the terminal window and choose Select All, then right-click again and choose Copy to transfer the information to the clipboard.
  
• Finally, open a text editor, paste the information from the clipboard into the editor program, and save it as a text file.

Since trace options can contain sensitive information, feel free to send it as an attachment via email to support@vandyke.com. Please reference "Attn Brenda - Forum Thread #12524" in the subject line.

NOTICE: The requested troubleshooting data may include sensitive information (usernames, passwords, publicly-accessible host names or IP addresses, etc.).

Please redact sensitive information that would not be appropriate for email communication prior to sending the requested information.

If there is sensitive information that must be conveyed in order to provide a complete picture of the scenario you're facing, please let us know and we will set up a secure upload mechanism that can be used.

[mr.dk]

[Master] Connection Connecting:

host is windows 10 Business and the other testing is on sCRT v8 is a windows 10 ultimate, but have admin user permissions.

[LOCAL] : SSH2Core version 7.2.0.606
[LOCAL] : Connecting to --------.-----:22 ...
[LOCAL] : Changing state from STATE_NOT_CONNECTED to STATE_EXPECT_KEX_INIT
[LOCAL] : Using protocol SSH2
[LOCAL] : RECV : Remote Identifier = 'SSH-2.0-OpenSSH_6.6.1p1 Ubuntu-8'
[LOCAL] : CAP : Remote can re-key
[LOCAL] : CAP : Remote sends language in password change requests
[LOCAL] : CAP : Remote sends algorithm name in PK_OK packets
[LOCAL] : CAP : Remote sends algorithm name in public key packets
[LOCAL] : CAP : Remote sends algorithm name in signatures
[LOCAL] : CAP : Remote sends error text in open failure packets
[LOCAL] : CAP : Remote sends name in service accept packets
[LOCAL] : CAP : Remote includes port number in x11 open packets
[LOCAL] : CAP : Remote uses 160 bit keys for SHA1 MAC
[LOCAL] : CAP : Remote supports new diffie-hellman group exchange messages
[LOCAL] : CAP : Remote correctly handles unknown SFTP extensions
[LOCAL] : CAP : Remote correctly encodes OID for gssapi
[LOCAL] : CAP : Remote correctly uses connected addresses in forwarded-tcpip requests
[LOCAL] : CAP : Remote can do SFTP version 4
[LOCAL] : CAP : Remote x.509v3 uses ASN.1 encoding for DSA signatures
[LOCAL] : CAP : Remote correctly handles zlib@openssh.com
[LOCAL] : SSPI : Requesting full delegation
[LOCAL] : SSPI : [Kerberos] SPN : host@--------.-----
[LOCAL] : SSPI : [Kerberos] InitializeSecurityContext() failed.
[LOCAL] : SSPI : [Kerberos] The specified target is unknown or unreachable
[LOCAL] : SSPI : [Kerberos] Disabling gss mechanism
[LOCAL] : GSS : Requesting full delegation
[LOCAL] : GSS : [Kerberos] SPN : host@--------.-----
[LOCAL] : GSS : [Kerberos] InitializeSecurityContext() failed.
[LOCAL] : GSS : [Kerberos] Could not load library 'gssapi64.dll': The specified module could not be found.
[LOCAL] : GSS : [Kerberos] Disabling gss mechanism
[LOCAL] : GSS : [Kerberos] Disabling gss mechanism
[LOCAL] : The following key exchange method has been filtered from the key exchange method list because it is not supported: gss-group1-sha1-toWM5Slw5Ew8Mqkay+al2g==
[LOCAL] : SSPI : Requesting full delegation
[LOCAL] : SSPI : [Kerberos (Group Exchange)] SPN : host@--------.-----
[LOCAL] : SSPI : [Kerberos (Group Exchange)] InitializeSecurityContext() failed.
[LOCAL] : SSPI : [Kerberos (Group Exchange)] The specified target is unknown or unreachable
[LOCAL] : SSPI : [Kerberos (Group Exchange)] Disabling gss mechanism
[LOCAL] : GSS : Requesting full delegation
[LOCAL] : GSS : [Kerberos (Group Exchange)] SPN : host@--------.-----
[LOCAL] : GSS : [Kerberos (Group Exchange)] InitializeSecurityContext() failed.
[LOCAL] : GSS : [Kerberos (Group Exchange)] Could not load library 'gssapi64.dll': The specified module could not be found.
[LOCAL] : GSS : [Kerberos (Group Exchange)] Disabling gss mechanism
[LOCAL] : GSS : [Kerberos (Group Exchange)] Disabling gss mechanism
[LOCAL] : The following key exchange method has been filtered from the key exchange method list because it is not supported: gss-gex-sha1-toWM5Slw5Ew8Mqkay+al2g==
[LOCAL] : SEND : KEXINIT
[LOCAL] : RECV : Read kexinit
[LOCAL] : Available Remote Kex Methods = curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
[LOCAL] : Selected Kex Method = diffie-hellman-group14-sha1
[LOCAL] : Available Remote Host Key Algos = ssh-rsa,ssh-dss,ecdsa-sha2-nistp256,ssh-ed25519
[LOCAL] : Selected Host Key Algo = ssh-dss
[LOCAL] : Available Remote Send Ciphers = aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-gcm@openssh.com,aes256-gcm@openssh.com,chacha20-poly1305@openssh.com,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
[LOCAL] : Selected Send Cipher = aes256-ctr
[LOCAL] : Available Remote Recv Ciphers = aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-gcm@openssh.com,aes256-gcm@openssh.com,chacha20-poly1305@openssh.com,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
[LOCAL] : Selected Recv Cipher = aes256-ctr
[LOCAL] : Available Remote Send Macs = hmac-md5-etm@openssh.com,hmac-sha1-e...60@openssh.com,hmac-sha1-96,hmac-md5-96
[LOCAL] : Selected Send Mac = hmac-sha2-512
[LOCAL] : Available Remote Recv Macs = hmac-md5-etm@openssh.com,hmac-sha1-e...60@openssh.com,hmac-sha1-96,hmac-md5-96
[LOCAL] : Selected Recv Mac = hmac-sha2-512
[LOCAL] : Available Remote Compressors = none,zlib@openssh.com
[LOCAL] : Selected Compressor = none
[LOCAL] : Available Remote Decompressors = none,zlib@openssh.com
[LOCAL] : Selected Decompressor = none
[LOCAL] : Changing state from STATE_EXPECT_KEX_INIT to STATE_KEY_EXCHANGE
[LOCAL] : SEND : KEXDH_INIT
[LOCAL] : RECV : KEXDH_REPLY
[LOCAL] : Changing state from STATE_KEY_EXCHANGE to STATE_READY_FOR_NEW_KEYS
[LOCAL] : RECV: Remote Hostkey: ------
[LOCAL] : SEND : NEWKEYS
[LOCAL] : Changing state from STATE_READY_FOR_NEW_KEYS to STATE_EXPECT_NEWKEYS
[LOCAL] : RECV : NEWKEYS
[LOCAL] : Changing state from STATE_EXPECT_NEWKEYS to STATE_CONNECTION
[LOCAL] : SEND: SERVICE_REQUEST[ssh-userauth]
[LOCAL] : RECV: SERVICE_ACCEPT[ssh-userauth] -- OK
[LOCAL] : SENT : USERAUTH_REQUEST [none]
[LOCAL] : RECV : USERAUTH_FAILURE, continuations [publickey]
[LOCAL] : SENT : USERAUTH_REQUEST [publickey (ssh-rsa) - unsigned,agent,fingerprint:------]
SecureCRT - Version 7.2.6 (x64 build 606)
[LOCAL] : SENT : USERAUTH_REQUEST [publickey (ssh-rsa) - signed,agent,May 2000 Standard]
[LOCAL] : RECV : AUTH_SUCCESS
[LOCAL] : SEND[0]: SSH_MSG_CHANNEL_OPEN('session')
[LOCAL] : SEND[0]: Pty Request (rows: 70, cols: 202)
[LOCAL] : RECV[0]: pty request succeeded
[LOCAL] : SEND[0]: agent forwarding request
[LOCAL] : RECV[0]: agent request succeeded
[LOCAL] : SEND[0]: exec request: -user ------- -password ------ -tenant ------- -host 000000
[LOCAL] : RECV[0]: exec request succeeded
SSH-2.0-OpenSSH_6.6.1

[mr.dk]

[Client] Connection Connecting, unsuccessful.


[LOCAL] : SSH2Core version 7.2.0.606
[LOCAL] : Connecting to -----:22 ...
[LOCAL] : Changing state from STATE_NOT_CONNECTED to STATE_CLOSED
[LOCAL] : Connected for 0 seconds, 0 bytes sent, 0 bytes received
[LOCAL] : Stream has closed [CLOSE_TYPE_NONSPECIFIC] : SOCKS connection not allowed by ruleset.
SecureCRT - Version 7.2.6 (x64 build 606)
Initializing Firewall[SOCKSv5]: 127.0.0.1:1080

SOCKS connection not allowed by ruleset.

[bgagnon]

Hi Derek,

Your trace options from the Master session doesn't show any port forwarding connection attempt. Did you copy the trace options output too soon?

You will need to wait until *after* you attempt to connect through the firewall (set up as a SOCKSv5 to the port forward addressort) so that the connection attempt by the SOCKS client (SecureCRT itself, it appears) gets traced in the Master session's trace options output.

[mr.dk]

Hello,

I checked again, no this is exactly correct as as seen.

[LOCAL] : SEND: SERVICE_REQUEST[ssh-userauth]
[LOCAL] : RECV: SERVICE_ACCEPT[ssh-userauth] -- OK
[LOCAL] : SENT : USERAUTH_REQUEST [none]
[LOCAL] : RECV : USERAUTH_FAILURE, continuations [publickey]
[LOCAL] : SENT : USERAUTH_REQUEST [publickey (ssh-rsa) - unsigned,fingerprint (SHA-2 hash): 7e:b6:9a:07:35:fa:8f:2a:89:e1:64:9c:50:45:bc:d0:b6:f2:b0:2d:c6:6c:dc:5d:5d:5f:cc:bc:02:64:80:b9]
[LOCAL] : SENT : USERAUTH_REQUEST [publickey (ssh-rsa) - unsigned,fingerprint (SHA-1 hash): 46:f1:af:27:9c:d2:59:17:dc:6a:6d:93:f5:b5:7d:aa:90:bd:32:a5]
[LOCAL] : SENT : USERAUTH_REQUEST [publickey (ssh-rsa) - unsigned,fingerprint (MD5 hash): 88:bc:8f:37:e9:36:5c:48:05:1b:a7:a1:67:03:8d:53]
[LOCAL] : SENT : USERAUTH_REQUEST [publickey (ssh-rsa) - signed,May 2000 Standard]
[LOCAL] : RECV : AUTH_SUCCESS
[LOCAL] : SEND[0]: SSH_MSG_CHANNEL_OPEN('session')
[LOCAL] : SEND[0]: Pty Request (rows: 70, cols: 175)
[LOCAL] : RECV[0]: pty request succeeded
[LOCAL] : SEND[0]: agent forwarding request
[LOCAL] : RECV[0]: agent request succeeded
[LOCAL] : SEND[0]: exec request: null -tenant ------ -host -------
[LOCAL] : RECV[0]: exec request succeeded



Dk

[mr.dk]

Hello,

I think we are getting off topic as well.

From DOS - I can telnet to port 1080 that seems to be opened correctly.

From SecureCRT I get the below when opening a client session... SOCKS connection not allowed by ruleset. This seems to be an internal issue to SecureCRT? without more debug I'm not sure what i can provide us?



Initializing Firewall[SOCKSv5]: 127.0.0.1:1080

[LOCAL] : SSH2Core version 8.0.0.1183
[LOCAL] : Connecting to sv-vpn:22 ...
[LOCAL] : Changing state from STATE_NOT_CONNECTED to STATE_CLOSED
[LOCAL] : Connected for 0 seconds, 0 bytes sent, 0 bytes received

[LOCAL] : Stream has closed [CLOSE_TYPE_NONSPECIFIC] : SOCKS connection not allowed by ruleset.
SecureCRT - Version 8.0.3 (x64 build 1183)

SOCKS connection not allowed by ruleset.

[mr.dk]

Ok, so I think I've figured out my issues ... unfortunately unsuccessfully.



What happens in my case:
[s] = server
[c] = client

[s] = Connection establishes no errors.
[c] = Opens the Socks on 1080
[s] = Starting port forward from 127.0.0.1 on local 127.0.0.1:1080 to remote client:22.
[s] = Could not start port forwarding from local service 127.0.0.1:59087 to client:22. Reason: Opening the channel was administratively prohibited. Server error details: open failed
[c] : Stream has closed [CLOSE_TYPE_NONSPECIFIC] : SOCKS connection not allowed by ruleset.



So since the server is unable to open the socket, the client fails with [CLOSE_TYPE_NONSPECIFIC] that is generic (can't open port) the the error message is misleading saying it is due to [SOCKS connection not allowed by ruleset]. As this would be likely the same error if you where blocked by a firewall, policy, ruleset the error message should be amended.


Thank you.
Dk

[jdev]

Originally Posted by mr.dk

Could not start port forwarding from local service 127.0.0.1:59087 to client:22. Reason: Opening the channel was administratively prohibited. Server error details: open failed

The remote SSH2 server on the other side is the one that's replying to SecureCRT's channel open request with a reason code 1: "SSH_OPEN_ADMINISTRATIVELY_PROHIBITED". SecureCRT translates this into "Opening the channel was administratively prohibited". SecureCRT also passes along the remote SSH2 server's "description" text, which in your case happens to be "open failed".

There isn't any additional information available to SecureCRT other than what was provided by the SSH2 server on the remote end after it attempted to open a connection to the destination on its side.

There are 4 different "reason codes" that an SSH2 server could choose to indicate if a channel open failure is to be sent to the SSH2 client:

             Symbolic name                           reason code
             -------------                           -----------
            SSH_OPEN_ADMINISTRATIVELY_PROHIBITED          1
            SSH_OPEN_CONNECT_FAILED                       2
            SSH_OPEN_UNKNOWN_CHANNEL_TYPE                 3
            SSH_OPEN_RESOURCE_SHORTAGE                    4

In your case, it would appear logical that the remote SSH2 server *should* have replied with a reason code of 2: CONNECT_FAILED.

SecureCRT isn't at fault, here. It can only operate on the information provided by the remote SSH2 server. Any attempts to do otherwise on SecureCRT's part would be arbitrary at best.

What it all means is that there isn't anything listening at the destination you labeled "remote client:22", or that there wasn't any network path to get there; it would be impossible for SecureCRT to convey this information to you since it can only pass along the information it receives from the SSH2 server.

The trick you used to help you better understand what was going on was to enable Trace Options output on your *Master* session -- the one that was providing the dynamic forwarding through to the remote SSH2 server.

--Jake