Chapter 10: Designing and Building SSL Remote Access VPNs (WebVPN)

Cisco Press

1 2 3 4 5 6 7 8 Page 4
Page 4 of 8

Figure 10-27 illustrates the port-forwarding concept. In Figure 10-27, on the client, traffic sent to IP address 127.0.0.x, TCP port 3389 (Windows Terminal Services) is redirected over SSL to the VPN 3000 concentrator. The VPN 3000 concentrator then forwards this traffic to the application server. Return traffic from the server is then sent to the VPN 3000 concentrator, which then forwards it over SSL to the client.

Configuration of port forwarding is fairly straightforward. The first step is to enable port forwarding by checking the Enable Port Forwarding box under the user group, as illustrated in Figure 10-22.

figure 10.27

Figure 10-27

The TCP Port-Forwarding Concept

After port forwarding has been enabled for the user group, it is then simply a case of going to Configuration > Tunneling and Security > WebVPN > Port Forwarding, clicking Add, and specifying TCP port forwarding parameters (see Figure 10-28).

The various boxes shown in Figure 10-28 are fairly self-explanatory.

You can enter a description for the application in the Name box—this is displayed on the remote access VPN client when the user enables application access.

Next, the port that the client uses to connect to the application should be specified in the Local TCP Port box. This setting controls which TCP traffic will be redirected over SSL to the VPN 3000 concentrator by the remote client. In the example shown, traffic using TCP port 3389 (the default Windows Terminal Services port) will be redirected over SSL to the VPN 3000 concentrator.

The IP address or name of the application server must then be entered in the Remote Server box.

If the IP address of applications servers are specified then they are accessed from the user workstation by specifying the IP address

If the names of application servers are specified, the hosts file on Windows user workstations are modified during WebVPN access, with the first application used for port forwarding being mapped to IP address, the second application being mapped to IP address, and so on.

figure 10.28

Figure 10-28

Configuring Port Forwarding

Finally, configure the TCP port that the application uses on the application server in the Remote TCP Port box. This TCP port will often be the same as that entered in the Local TCP Port box.

Click Add, and port forwarding will be ready for use for the particular application just configured.

For port forwarding to function, the Sun JRE must be installed on the clients, and this requires the person installing the software have administrative rights on that workstation. Because administrative rights are required for the installation of the JRE, it is unlikely that remote access users will be able to access applications using port forwarding from locations such as Internet cafes or airport Internet kiosks.

Note - JRE can be downloaded from the Sun website. At the time of this writing, the download location is as follows:

Note that Microsoft Java cannot be used for port forwarding.

Also, make sure that either Negotiate SSLv3 or Negotiate SSLv3/TLS is chosen under Configuration > Tunneling and Security > SSL > Protocols. If one of these two options is not chosen, port forwarding will not function.

Remote access VPN users must connect to the VPN 3000 concentrator and access their home page using their web browser. Users can then click the Start Application Access link on either the home page itself or on the pop-up dialog box (make sure that pop-ups are allowed!) to enable application port forwarding for the SSL connection. Take a look back at Figure 10-23 to see the Start Application Access link on the home page.

When a user clicks the Start Application Access link, a Java applet opens the Application Access window on the client, and application port forwarding is enabled.

Figure 10-29 shows access to Windows Terminal Services using port forwarding over SSL.

figure 10.29

Figure 10-29

Access to Windows Terminal Services Using Port Forwarding over SSL

In the upper-left corner of the screen in Figure 10-29, you can see the Application Access window. As you can see, it lists the application names, associated local and remote TCP ports, remote application server IP addresses, the number of application data bytes sent (Bytes Out) and received (Bytes In), and the number of sockets open for particular applications. The application names, TCP ports, and remote application server IP addresses are, as previously described, configured under Configuration > Tunneling and Security > WebVPN > Port Forwarding (see Figure 10-22).

The main window in Figure 10-29 shows the remote desktop on the remote Windows Terminal Server accessed via the VPN 3000 concentrator.

One important detail in Figure 10-29 is the local IP address used to access the remote TCP application. Notice that the local IP address shown in the Application Access window (and in the upper-left corner of the main window) is This is the IP address that is typed into the Computer box of the Remote Desktop Connection application used on Windows XP to access the Windows Terminal Server. Of course, 127.0.0.x is used to specify the local system, and this (TCP) traffic is then redirected over SSL to the VPN 3000 concentrator.

As previously mentioned, when using DNS names, the redirection of application traffic that port forwarding relies upon is achieved by the modification of the local system's Hosts file. The Hosts file is modified when application access is enabled (a copy of the original file is saved during application access, and restored later).

Figure 10-30 shows a modified Hosts file that enables application traffic redirection during application access.

figure 10.30

Figure 10-30

Modified Hosts File

In Figure 10-30, the Hosts file has been modified to include four entries, two corresponding to port forwarding to ( and two corresponding to (

When enabling an application for port forwarding over SSL, it is important to establish that the application is, in fact, TCP based, and if so, which TCP ports it uses. After this information has been confirmed and obtained, the application should be enabled for port forwarding in a similar manner to that for Windows Terminal Services described in this section.

If you want to enable a remote access VPN user to Telnet to a terminal server (router) via the VPN 3000 concentrator, for example, you first need to establish that the application is TCP based (it is, of course), and the TCP port(s) that it uses (port 23).

After these facts have been established, port forwarding for Telnet to the terminal server can be configured as shown in Figure 10-31.

figure 10.31

Figure 10-31

Configuring Port Forwarding for Telnet

In Figure 10-31, the name Telnet To Term Server has been configured for the Telnet port forwarding connection. This name is, of course, displayed on the WebVPN home page and in the Application Access window.

The local and remote TCP ports are configured as 23, and the remote server (terminal server) IP address is configured as (an internal IP address).

Figure 10-32 shows how Telnet to the terminal server functions on a remote access VPN client. As shown, the user Telnets to the local IP address (127.0.0.x) to connect to the remote terminal server. Telnet packets are then redirected over SSL to the VPN 3000 concentrator that then proxies the Telnet connection to the terminal server.

figure 10.32

Figure 10-32

Port Forwarding for Telnet on a Remote Access VPN Client

Configuring E-mail Proxy for SSL Remote Access VPN Users

E-mail proxy describes the process by which the VPN 3000 concentrator terminates POP3S (POP3 over SSL), IMAP4S (IMAP4 over SSL), and STMPS (SMTP over SSL) connections from remote access VPN clients and proxies those connections to internal e-mail servers.

Figure 10-33 depicts e-mail proxy for POP3S, IMAP4S, and SMTPS connections from remote access VPN clients.

In Figure 10-33, remote access VPN user Mark is using an e-mail client such as Outlook Express. His e-mail client is configured to connect to the VPN 3000 concentrator using POP3S (for incoming e-mail) and SMTPS for outgoing e-mail. The VPN 3000 concentrator proxies these connections to an internal e-mail server.

The configuration of e-mail proxy consists of enabling the appropriate e-mail protocols on the public interface and then configuring protocol port numbers, e-mail server IP addresses or names, and methods of authentication.

Enabling e-mail protocols (POP3S, IMAP4S, and SMTPS) on the public interface of the VPN 3000 concentrator by going to Configuration > Interfaces, choosing the public interface, and clicking the WebVPN tab. See Figure 10-18 on page 929 for information on the method of enabling e-mail protocols.

figure 10.33

Figure 10-33

E-Mail Proxy for POP3S, IMAP4S, and SMTPS Connections

You can configure e-mail protocol port numbers, e-mail server IP addresses or names, and methods of authentication under Configuration > Tunneling and Security > WebVPN > Email Proxy (see Figure 10-34).

The first two parameters (VPN Name Delimiter and Service Delimiter) are, as their names suggest, used to delimit VPN and e-mail server usernames and passwords.

The VPN Name Delimiter is used to separate the VPN usernames/passwords and e-mail server usernames/passwords. This delimiter is used when configuring the e-mail client—in the box on the e-mail client where the username is entered, the username that the VPN 3000 concentrator uses to authenticate the user, as well as the username that the e-mail server uses to authenticate the user must be configured. These usernames are separated in the box using the delimiting character specified by the VPN Name Delimiter.

So, for example, if the username used to authenticate the user on the VPN 3000 concentrator is mark, the username used to authenticate the user on the e-mail server is markj, and the delimiting character specified on the VPN 3000 concentrator is :, then mark:markj should be entered into the username box on the e-mail client (more on this later).

figure 10.34

Figure 10-34

Configuring E-Mail Protocol Ports, Server Addresses or Names, and Methods of Authentication

Similarly, the Service Delimiter is used to separate the e-mail server username from the e-mail server name itself. The default is @, which is often the delimiting character used on e-mail servers. If the delimiting character is different for your e-mail servers, the Service Delimiter should be modified using the drop-down box as appropriate.

Underneath the VPN Name Delimiter and Service Delimiter parameters are the settings for POP3S, IMAP4, and SMTPS ports, default e-mail server IP addresses or names, and methods of authentication.

The ports used for POP3S, IMAP4S, and SMTPS must match those specified on e-mail clients.

The default e-mail server IP addresses or DNS names should be entered into the appropriate boxes. Note that these are the mail servers to which e-mail traffic is sent when e-mail client do not explicitly specify e-mail servers.

As far as methods of authentication are concerned, it is possible to use one or more of the four different methods of authentication for POP3S, IMAP4S, and SMTPS:

  • Email Server—If this box is checked then it indicates that the e-mail server(s) will authenticate POP3S, IMAP4S, and SMTPS. This box must be checked for POP3S and IMAP4S.

  • Concentrator—This box must be checked if authentication of users on the VPN 3000 concentrator is also required.

  • In this case, the e-mail server and concentrator usernames passwords must be separated in the e-mail clients' configuration using the VPN Name Delimiter character, as previously described.

  • Piggyback HTTPS—When this box is checked, a regular HTTPS (WebVPN) session must have already been established via a web browser with the VPN 3000 concentrator.

  • Certificate—If this box is checked, clients are required to authenticate themselves during the RSA handshake using a certificate.

Client configuration is fairly simple—clients should be configured such that they point to the VPN 3000 concentrator instead of directly to an e-mail server.

If you are using Outlook Express, for example, you must configure an e-mail account as normal; if you are using VPN 3000 concentrator authentication in addition to e-mail server authentication for POP3S or IMAP4S, however, you must configure the username and password appropriately (see Figure 10-35).

figure 10.35

Figure 10-35

Configuring the Username and Password on Outlook Express When Using E-Mail Proxy

If you take a look under the "Incoming Mail Server" header in the Servers tab of the account properties, you will notice that the account name is mark:markj.

Because e-mail proxy via the VPN 3000 concentrator is being used, and Concentrator authentication is configured (see the Concentrator box in Figure 10-34), the VPN 3000 concentrator username (mark) is specified first, and the e-mail account name (markj) is specified next. The two usernames are separated using the VPN Name Delimiter (:) specified on the VPN 3000 concentrator (again, see Figure 10-34). If the usernames on both the VPN 3000 concentrator and the e-mail server are the same, it is only necessary to specify the username once (for example, mark).

Now, if the e-mail client in question wants to access e-mail on a mail server that is not the default (see configuration of Default E-Mail Server in Figure 10-34), the e-mail server name must be specified in this same box in this format:

(e-mail_server_username)[Server Delimiter](e-mail_server_name)

So, if the e-mail server is (not the default specified in Figure 10-34), the account name should be

1 2 3 4 5 6 7 8 Page 4
Page 4 of 8