How to Pass the Client's Source Port to the Backend Server When Accessed Through NetScaler

To achieve this, we would have to disable the Use Proxy Port option.

To configure the Use Proxy Port setting on a service by using the configuration utility:

  1. Navigate to Traffic Management> Load Balancing > Services, and open a service.
  2. In Advanced Settings, select Traffic Settings, and unselect Use Proxy Port.

To configure the Use Proxy Port setting on a service by using the CLI:

At the command prompt, type:

set service svc -useproxyport NO

The Use Proxy Port option works only when the Use Source IP/ Use Client IP option is enabled on the Service/Service Group respectively.

Also, this option is enabled by default for TCP-based service types, such as TCP, HTTP, and SSL,

This will allow the backend server to see client IP and source port from which the client tries to connect.

Related:

  • No Related Posts

How can specify URL for TCP tunneling requests for Line Application?

I need a solution

     I have to disable Tunnel on Protocol Error function because it allow client to use unwanted protocol over HTTPS such as SSH. But the problem is client still need to use Line Application which need to do TCP tunneling. Right now, I have to manually created service group, use TCP tunnel with detect protocol for them in all proxies and worse than that is I have to specify the destination using IP address only.

     Line Application has been updated a lot. It’s been changed or added more IP address almost every updated. When the update happen, client always face some problem such as cannot login or cannot view or send pictures, stickers or files. The only way I can know what’s going on is I have to run packet capture on them and see which destination IP address has a problem and add it to service group.

     It would be nice if I can specify destination by URL for TCP tunneling or if you have other solution for me, please advice.

 

0

Related:

Understanding Explicit HTTP Intercept Proxy Protocol

I need a solution

So I’m new to Blue Coat Proxy and proxies in general, but am an experienced network person. I work in a (new) environment where we use BC proxies; and browsers are essentially setup to use proxy TCP port 74. Likewise, in our BC, our proxy services Predefinied Service Group Explicit HTTP iis setup for Explicit port 74 and to intercept. 

If I look at my browser traffic on wireshark, I see unreadable/undecoded payload within TCP port 74. Is this SOCKS protocol? Or just HTTP within port 74 and wireshark doesn’t know how to decode it because it isn’t in it’s library? I believe the IT forefathers simply picked TCP port 74 as a tunneling protocol due to it’s liklihood of being unique in our environment. I’m just trying to understand what the protocol is between the browser and BC Proxy, or whether it’s simply HTTP tunneled between TCP port 74.

This is really bothering me that I don’t understand.

Thanks! 

0

Related:

ProxySG-Policy evalution

I need a solution

Hi Team,

We have transparent mode setup. Client enable TCP tunnel services in the protocol.

We have configured block rule to block social media and porn categories.

But user can access those blocked category url’s. whicl we are checking in the policy trace it shows in the IP addresses instead of the url

tunnel: get :/63.53.67.12

Even those rule is not matching in the policy execution.

Please advise on this.

Thanks,

Ram.

0

1532053962

Related:

TCP tunnel requests when a protocol error is detected

I need a solution

Hi guys 

in the transparence mode

When enable  “TCP tunnel requests when a protocol error is detected ” 

– Where to see the tunnel sessions ?

– The tunnel seesions by “TCP tunnel requests when a protocol error is detected ”  can not apply to the policy in VPM correct ? 

When create Service by Source IP address and port | Proxy :TCP Tunnel | Intercept 

– The tunnel seesions can apply to the source  policy in the VPM   but destiantion policy can’t correct  ? 

BR 

PK

0

Related:

7021485: Telnet Port Forwarding and the Reflection Secure Shell Client

A Brief Introduction to SSH

SSH is a set of computer applications based on the IETF Internet-Draft for the Secure Shell protocol. SSH provides strong, encrypted authentication and a secure encrypted tunnel through which users can execute commands and move data. The current version of Secure Shell is ssh-2. (The ssh-1 protocol is deprecated; therefore, it is highly recommended that you use ssh-2.)

For more information about Secure Shell, see “Fortified SSH: A Cost-Effective Way to Safeguard Your Network” on the Attachmate web site at http://www.attachmate.com/WhitePapers/Literature_0954.htm.

Using Reflection Secure Shell Client for Secure Connections

The Reflection Secure Shell Client is included in Reflection version 12.0 or higher.

To tunnel a Telnet session through an SSH connection, you must establish the SSH connection, then configure Reflection to redirect Telnet through the SSH tunnel. To do this, you must create two Reflection settings files, one to configure and start SSH, and one to configure and start the Telnet session.

Figure 1 - Telnet Port Forwarding
Figure 1 – Telnet Port Forwarding

Note: Both connections must remain open for port forwarding to be available. The SSH connection window may be minimized. If the user tries to log off or close the SSH connection while the Telnet session is being tunneled, they will be unable to do so. The SSH session will remain open until the Telnet session is terminated.

Step I—Create the SSH Connection Settings File

Follow the steps below (for the appropriate Reflection product) to create a settings file that opens a Secure Shell connection to your secure host.

For Reflection 2014 or Reflection 2011

  1. Verify with your host administrator that an SSH daemon (sshd or sshd2) is running on the host computer.
  2. Start the Reflection Workspace, select an IBM or VT terminal template, and then click Create.
  3. Select the Secure Shell radio button.
  4. Enter the Host name and your User name.
  5. Select the Configure additional settings check box, and then click OK.
  6. Click Set Up Connection Security.
  7. On the Tunneling tab, under Local Forwarding, click Add.
  8. In the “Forward local port” field, enter the local Telnet port. The example below uses port 1025. Port numbers higher than 1025 are user-defined ports. Using ports 1 – 1024 requires administrative privileges.
  9. Under Destination Host, in the Name field, enter localhost, and in the Port field, enter 23.

Important: Localhost is used for the remote machine if the Telnet server you are connecting to is running on the same server where the SSH daemon resides, which is often the case.

If the SSH daemon resides on a different host than the host you are connecting to with Telnet, enter the name of the host you are connecting to with Telnet in the ‘to remote’ field. In this instance, the telnet connection between the Reflection Secure Shell client and the SSH daemon is secure, but the Telnet connection between the SSH daemon and the target host is not secure.

  1. Click OK > OK > OK.
  2. To verify that you can successfully establish the Secure Shell connection, log in to the host. Once successfully connected, click Disconnect.
  3. Click the Save icon. Enter a descriptive file name for this Secure Shell connection and click Save.

For Reflection 14.x

  1. Verify with your host administrator that an SSH daemon (sshd or sshd2) is running on the host computer.
  2. Start Reflection.
  3. Click Connection > Connection Setup.
  4. Under Connect using, select Network and Secure Shell.
  5. Under Connection options, enter the Host name, your User name, and then click Security.
  6. Click the Tunneling tab. Under Local Forwarding, click Add.
  7. In the ‘Forward local’ field, enter the local Telnet port. The example below uses port 1025. Port number 1025 or higher are user-defined ports. Using ports 1 – 1024 requires administrative privileges.
  8. In the ‘to remote’ field, enter localhost, and in the ‘port’ field, enter 23.

Important: Localhost is used for the remote machine if the Telnet server you are connecting to is running on the same server where the SSH daemon resides, which is often the case.

If the SSH daemon resides on a different host than the host you are connecting to with telnet, enter the name of the host you are connecting to with telnet in the ‘to remote’ field. In this instance, the telnet connection between the Reflection Secure Shell client and the SSH daemon is secure, but the telnet connection between the SSH daemon and the target host is not secure.

Figure 2 - Add Local Port Forwarding

Figure 2 – Add Local Port Forwarding

  1. Click OK to close dialog boxes and return to the Connection Setup dialog box.
  2. Click Connect and verify that you can successfully establish the Secure Shell connection. Once connected, click Connection > Disconnect.
  3. Click File > Save. Enter a descriptive file name for this Secure Shell connection and click Save.

Step II—Create the Telnet Connection Settings File

Follow the steps below to create a settings file that starts a Telnet session over the port that you have redirected to connect through SSH.

For Reflection 2014 or Reflection 2011

  1. In the Reflection Workspace, click the New Document icon.
Figure 3 - Reflection Workspace New Document Icon
Figure 3 – Reflection Workspace New Document Icon
  1. Select a template and then click Create.
  2. Select the Telnet radio button.
  3. In the “Host name / IP address” field, enter localhost.
  4. In the Port field, enter port 1025 (or whatever port number you configured in step I-8 above), and then click OK.
  5. Click OK in the “Host: localhost” error dialog box. (The error occurs because the SSH connection settings file is not currently loaded.)
  6. Click the Save icon. Enter a descriptive file name for this Telnet connection and click Save.

For Reflection 14.x

  1. Open Reflection and then click Connection > Connection Setup.
  2. Under Connect using, select Network and Telnet. In the ‘Host name’ field, enter localhost, and then click More Settings.
  3. On the General tab, select TCP port 1025 (or whatever port number you configured in step I-8 above), and then click OK.
  4. Click File > Save. Enter a descriptive file name for this Telnet connection and click Save.

Step III—Tunnel the Telnet Connection through the SSH Connection

Once you have created the Secure Shell and Telnet settings files, follow these steps to tunnel Telnet through the secure pipe.

  1. Double-click the Secure Shell settings file you saved in Step I-12 (Reflection 2014 or 2011) or Step I-11 (Reflection 14.x).
  2. Enter your password. An SSH connection is established.
  3. With the SSH connection established (you may minimize the Reflection window, but do not close it), double-click the Telnet settings file you saved in Step II-4. A Telnet session will be started through the SSH tunnel.
  4. Enter your user name and password.

Verify the Secure Connection

Follow the steps below to verify that your Telnet session is running through the SSH tunnel.

  1. Click Start > Run.
  2. In the Open field, type cmd, and then click OK.
  3. In the Windows Command window, type netstat.

Note: If the netstat command is not recognized, navigate to the C:WindowsSystem32 directory and enter the command again.

If the port forwarding is successful, you should see a response similar to the following:

Active Connections

Proto Local Address Foreign Address State

TCP MY_PC:2460 my.server.com:22 ESTABLISHED

TCP MY_PC:1025 localhost:2461 ESTABLISHED

TCP MY_PC:2461 localhost:1025 ESTABLISHED

In the example above, the first TCP row shows the SSH connection from port 2460 (a random port) on the workstation to port 22 (the default SSH port) on the SSH server.

The second and third TCP rows show the Telnet connection between port 1025 on the workstation, the port that has been configured to redirect Telnet connections (port 23) through the SSH tunnel (port 22), and a random port (2461) on the SSH server.

Note: If the second or third row shows the actual host name, such as my.server.com, instead of localhost, the tunnel has failed and the Telnet connection is not encrypted.

Related: