[Dr.WoW] [No.42] Port Forwarding Highlighted

Latest reply: Oct 16, 2015 04:05:45 2859 1 1 1

File sharing and Web proxies can address the majority of remote users' needs for access to internal resources, however, under some circumstances (for example for access to TCP-based non-Web applications such as Telnet, SSH, email, etc.), file sharing and Web proxies appear to be helpless. However, it is not this way in practice, and in this section I will introduce port forwarding, SSL VPN's third remarkable function, to everyone.

Port forwarding, to put things simply, is using a special port forwarding client program on the remote user side to obtain a user's access requests, and then forwarding these to the internal network's corresponding server through the virtual gateway. Next, we'll use Telnet access, the most commonly used application, as an example to introduce the configuration and processes involved in remote clients accessing internal networks through SSL VPNs.

1 Configuring Port Forwarding

A port forwarding use scenario is shown in Figure 1-1.

Figure 1-1 Port forwarding use scenario

[Dr.WoW] [No.42] Port Forwarding-1305827-1 

Just as with the other SSL VPN functions introduced above, regardless of what kind of application is being accessed, corresponding resources need to first be added to the virtual gateway. For Telnet, all that is required is to configure a Telnet server's IP address and port on the virtual gateway, as shown in Figure 1-2.

Figure 1-2 Port forwardingadding a new resource.

[Dr.WoW] [No.42] Port Forwarding-1305827-2 

There are two methods to enable the port forwarding function. The first is for the remote user to choose to manually enable the port forwarding function in the virtual gateway interface that appears after login. The second is for the administrator to set configuration as being automatically enabled on the client after login, as shown in Figure 1-3. In addition to being able to automatically enable the port forwarding function, the administrator can also choose whether or not to maintain long port forwarding connections. This is important because as some applications' access continues for a relatively long time (for example, if the remote user suddenly needs to leave for a period of time while operating Telnet), after this is selected it can prevent the interruption of the port forwarding service due to the SSL connection timing out and disconnected.

Figure 1-3 Configuring port forwarding

[Dr.WoW] [No.42] Port Forwarding-1305827-3 

The data handling process for port forwarding is comparatively complex. Here, I'll give a simple figure (Figure 1-4), and will go through each step from this bit by bit below.

Figure 1-4 Port forwarding handling process

 

[Dr.WoW] [No.42] Port Forwarding-1305827-4 

NOTE: The port forwarding client here contains the SSL VPN client function, and is only called by this name in order to emphasize its port forwarding service.

2 Preparatory Stage

1.         Log in to the SSL VPN

This process has already been introduced in "8.1.2 SSL VPN Use Scenarios" and will not be elaborated upon further here.

In addition, everyone needs to be aware that in the above sections I've focused on URLs in beginning my ***ysis, but our ***ysis of port forwarding will be different. Although we're once again logged in to the virtual gateway, because this is non-Web application access, the Web is no longer used for the corresponding resource access, and instead other applications, such as Putty (a Telnet/SSH tool), Filezilla (an FTP tool), and Foxmail (an email program) are used. This gives rise to a question-- how does a non-Web application make use of an already logged in SSL VPN to connect?

2.         The port forwarding client enters the "listening" state.

It would seem that using a non-Web application for data access shouldn't involve an SSL VPN, but in reality, the key technological point of port forwarding is displayed here: after a user uses the Windows operating system's IE browser to log in to the virtual gateway, their local PC's IE browser will automatically run the port forwarding client (Active X control). The role of this client is to constantly "listen" to all requests from other programs (making the client an 'All-Hearing Listener'; we'll call it the 'Listener' at times below), "intercept" requests remote users send to the internal network server at important moments, and then send these to the virtual gateway over the SSL connection. Of the requests it "listens to", the Listener doesn't unilaterally choose which requests to intercept, but instead strictly implements the instructions given to it by its 'superior officer', the virtual gateway. Now, what orders are given?

The port forwarding resource configured above is actually the order issued to the port forwarding client by the virtual gateway: "if a user wants to access this resource, please assist them in completing their access tasks." In the port forwarding function, the orders given are the destination host IP address+destination port, and only the aforesaid information can confirm the application information the remote user wants to access.

As shown in Figure 1-5, after a remote user manually enables the port forwarding function, the port forwarding client will automatically request resource information from the virtual gateway. The resource information successfully requested by the client will be saved in the remote user's PC's memory, and will wait for further orders, to aid in subsequent selection of which requests are to be "intercepted."

Figure 1-5 Port forwarding―initiation

[Dr.WoW] [No.42] Port Forwarding-1305827-5 

So that the internal network server address is not disclosed, specific resource information cannot be viewed on the port forwarding client, and the resources in the menu can't be directly clicked on and thus serve only a simple notification role.

3 Telnet Connection Establishment Stage

1.         Accurate interception by the Listener and display of its proxy abilities

The Listener's 'mind' is now clear as to which requests it needs to "intercept", and the next thing to do is to use its 'ears' and listen to the content it is concerned with. When a user uses the Telnet protocol to request a connection to 10.1.1.1's port 23 (a TCP SYN packet), the Listener discover that this matches the resource information (destination IP+destination address) issued by its commanding officer (the virtual gateway), and immediately "intercepts" this TCP SYN packet. If the normal method was used, at this time the request packet would be sent to the virtual gateway by the Listener per its duty, but here the Listener considers that if this is sent to the virtual gateway without further processing, this will result in every Telnet request (that is, every TCP connection) correspondingly establishing a new SSL connection, which would not only occupy too many system resources, but also delay response speed.

In order to conserve the virtual gateway's session and memory resources and improve the user experience, the Listener decides to first disguise itself as the receiver, and simulate reception of a Telnet service request (TCP connection) to determine exactly what kind of resources the user wants to access―the strategy it is using here is a centralized proxy method that seeks a one SSL connection solution to lessen the pressure on its superior officer (the virtual gateway). How can receipt of Telnet services be simulated? And how can centralized proxy services be provided? The Listener, this outstanding proxy, has an ingenious plan:

After the port forwarding client receives a Telnet request, it modifies the packet, changing the original request that was to be sent to 10.1.1.1 to being sent to itself (127.0.0.1). This is equivalent to substituting itself in place of the Telnet server in receiving the request. However, a simulation is still just a simulation, and at the same time as the simulation it must record the corresponding pre-modification and post-modification relationship, so that it can subsequently reply to the real user (4.1.64.179) in place of the Telnet server.

The port forwarding client establishes TCP Connection 1 (also called the local loopback connection) with itself. Use of the netstat command provides the following verification of this:

C:\> netstat -anp tcp

 

Active Connections

 

  Protocol Local address          External Address          Status

  TCP    127.0.0.1:1047        0.0.0.0:0              LISTENING

  TCP    127.0.0.1:1047        127.0.0.1:7319        ESTABLISHED

  TCP    127.0.0.1:7319        127.0.0.1:1047        ESTABLISHED

2.         Creating a private packet header, and submitting the "port forwarding service list".

After the simulated receipt of a Telnet service request, the port forwarding client has a complete understanding of the user's request, and needs to complete the "port forwarding service list" and submit this to it's the virtual gateway in accordance with procedural requirements. The service list must include the destination address (10.1.1.1) and port (23) requested by the user, as well as a command word (to establish a connection, transfer data packets, or close the connection, etc.) so that the virtual gateway can carry out further processing.

Here we need to note that as the port forwarding client itself simulated the receiver's establishment of TCP Connection 1, there must be a marker (TCP Connection 1's socket ID, called the client socket ID) in the service list of this TCP Connection. Only in this way can the port forwarding client use the marker to find TCP Connection 1 when the superior officer returns the service handled results, and then send the return results to the corresponding Telnet client.

The port forwarding service list is called a private packet header (or simply a private header) during the port forwarding service, as shown in Table 1-1. Here, we'll only look at Telnet request connection packets, and will explain the primary fields in the private packet header. In the Telnet connection establishment stage the packet's payload is empty, so during transmission there is only a private packet header; the packet doesn't have a payload until the data transfer stage.

Table 1-1 Port forwarding private packet header

Field name

Field details

User marker

Marks the user's identity, and is automatically assigned for the user by the virtual gateway. This can be understood to be the port forwarding service list number.

Command word

Open- create a new connection

Data- data command

Close-close connection

Service type

Port forwarding

Web-Link

Web-Link is actually HTTP/HTTPS's port forward service. Or to put things another way, Web-Link resources can likewise also be configured as port forwarding resources. But please remember that a well-known port does not need to be designated for Web-Link resources, for example http://www.huawei.com/, but in configuring port forwarding the port number is mandatory, for example, HTTP's well-known port number 80 and HTTPS's 443.

Source IP Address

The source IP address for the original request. In this example this is the remote user's client address: 4.1.64.179.

Destination IP address.

The destination IP address from the original request. In this example this is the internal network's Telnet address: 10.1.1.1.

Protocol type

At the moment only the TCP protocol is supported.

Destination port

The destination port in the original request. In this example this is the internal network Telnet port 23.

Client socket ID.

The socket ID used to establish a connection between the remote user and the firewall. This is used to identify this session; subsequent packets will continue to use this socket ID.

Server socket ID

The socket ID used to establish a connection between the firewall (serving as the Telnet client) and the internal network server. This has the same role as the client socket ID―both are used to identify the session.

 

After organization of the port forwarding transaction list is complete it is encrypted and sent to the virtual gateway using the SSL connection.

It is important to note that what it is established here is an SSL connection specially used for the port forwarding service, not the SSL connection that was established during login. When Telnet initiates similar access requests to other resources, and after it establishes a new TCP connection, the port forwarding client will also again complete a port forwarding service list, and send it via this SSL connection. In this way, an exclusive SSL connection will always be maintained between the client and virtual gateway. To summarize, all port forwarding service lists will be sent first to this SSL connection, and will then be sent to the virtual gateway after encryption, greatly reducing the virtual gateway's workload.

3.         Establishing a connection between the virtual gateway and the internal network server

The virtual gateway receives the encrypted packet, decrypts it, and obtains the real Telnet destination IP address and port, the command key and other information from the port forwarding service list. At this point, the virtual gateway will serve as the Telnet client and interact with the internal network server to establish a Telnet connection. A check of the firewall's session table shows that the firewall randomly enabled port 10010 to initiate an access request to 10.1.1.1:23, establishing TCP connection 2:

telnet  VPN:public --> public 10.1.1.2:10010-->10.1.1.1:23

4.         The internal network server's response packet returns to the Telnet client.

The virtual gateway receives the internal network server's response packet (login interface), and before sending it to the remote client, the virtual gateway will still construct a private packet header, and fill in TCP Connection 2's socket ID (the server socket ID); this allows it to establish a relationship with TCP Connection 1. Finally, the virtual gateway sends the SSL encrypted private packet header +data to the port forwarding client through the SSL; the port forwarding client finds TCP Connection 1 based upon the client socket ID in the private header, then finds the Telnet client's real IP address, and finally returns the real data.

SSL-decrypted data received by the port forwarding client is shown below. In the portion highlighted in the screenshot, the login page's text can already be vaguely seen (this is the Telnet data packet), and the content in the upper content is the private header's content.

[Dr.WoW] [No.42] Port Forwarding-1305827-6 

4 Data Communication Stage

Subsequent Telnet data packets will continue to use the previously established TCP Connection 1 and TCP Connection 2, and will associate the two connections using private packet headers, finally opening a Telnet client- port forwarding client- virtual gateway-Telnet server transmission channel, allowing for data communication to be achieved.

The introduction to the Telnet application port forwarding process concludes here. The Telnet protocol is only a single channel protocol, the simplest kind of protocol. In addition to this, port forwarding also supports the following types of applications:

l   Multiple-channel protocols, supporting FTP and Oracle SQL Net. During actual configuration, only the control channel's port 21 needs to be designated for the FTP protocol; negotiated data ports will be passively "listened" to, and additional configuration is not required.

l   Multiple protocol applications. Some applications require the support of multiple protocols. Take email for example: prior to configuring the port forwarding service, the port numbers of the sending protocol (SMTP:25) and the receiving protocol (POP3:110 or IMAP:143) must be configured, as must a port forwarding resource for each type of protocol.

l   Multiple IP fixed port applications. Using IBM Lotus Notes as an example, its corresponding databases are on multiple servers, however, when providing external service, only the 1352 port is used. When this type of application configures the port forwarding service, traversal configuration does not need to be made for all servers. Instead, we can simply select "Any IP address" from "Host address type".

In real-world scenarios, the configuration and use of port forwarding is extremely simple (of course it is― this is an SSL VPN after all!), but what you don't see is how much behind-the-scenes work goes into creating this marvelous functionality. You may not use such abstract content frequently, but just trust that when the need does arrive, my words will appear again and help you discover ways to improve your VPN connection even further.

 

 

 

 

To view the list of all Dr. WoW technical posts, click here.

  • x
  • convention:

user_2790689
Created Oct 16, 2015 04:05:45 Helpful(0) Helpful(0)

Thank you.
  • x
  • convention:

Reply

Reply
You need to log in to reply to the post Login | Register

Notice Notice: To protect the legitimate rights and interests of you, the community, and third parties, do not release content that may bring legal risks to all parties, including but are not limited to the following:
  • Politically sensitive content
  • Content concerning pornography, gambling, and drug abuse
  • Content that may disclose or infringe upon others ' commercial secrets, intellectual properties, including trade marks, copyrights, and patents, and personal privacy
Do not share your account and password with others. All operations performed using your account will be regarded as your own actions and all consequences arising therefrom will be borne by you. For details, see " Privacy."
If the attachment button is not available, update the Adobe Flash Player to the latest version!
Login and enjoy all the member benefits

Login and enjoy all the member benefits

Login