In labs 9 and 9.5, we configured clientless SSL VPN, which allows users to remotely access internal resources through a secure web browser without needing a pre-installed client. We customized the SSL VPN service using our own logo and texts and also added accessible web servers to the SSL VPN portal. However, what happens if remote users need access to TCP connections such as SSH or Telnet? Clientless SSL VPN does not provide access to such services but thin-client does, which we will be configuring in this lab.

Our network diagram is as shown below:

The configuration tasks for Lab #10 are as follows:

  • * Edit the Clientless SSL VPN configuration such that connected users have telnet access to 1.1.1.1 on localhost port 20023 and SSH access to 2.2.2.2 on localhost port 20022.
  • * Test your SSL VPN service. Ensure that SSL VPN users can access both servers through the SSL VPN portal.

Configuration Solutions

Thin-client SSL VPN, also called port forwarding, provides secure access to fixed TCP port services such as SSH, Telnet, and SMTP. After successfully connecting to the SSL VPN portal, the user must download a Java applet to be able to securely connect to these services. Note that UDP is not permitted, neither does port forwarding work with TCP services that do not use a static port number such as FTP. Also, administrative access is required to run the applet on the remote user’s machine.

To begin our configuration, I will navigate to Configure > Security > VPN > SSL VPN > SSL VPN Manager. Under the Edit SSL VPN tab, I will click on the Edit button and select the Port Forward Lists option.

I will use the Add button to add a Port Forward List.

I will name this port forward list PF_Servers and then add the two servers under this list.

To add servers to the list using the dialog box above, we will enter the real IP address of the server (e.g. 1.1.1.1) in the Server IP Address field; the server port will be 23 for Telnet and 22 for SSH. The port on the client PC will be 20023 and 20022, as given by the task. Finally, we will assign a description. The screenshot below shows my configuration:

Note: For some weird reason, CCP flips the ports on Port Forward List screen. Compare the screenshot above to the one below:

Now that we have configured the Port Forward List, we need to add it under the Web VPN policy. Still on the Edit SSL VPN Context screen, I will select the Group Policies option so that I can edit the policy.

In the Edit Group Policy dialog box, I will select the Thin Client tab and click the option to Enable Thin Client, as shown below. Notice that the Port Forward List I created is automatically selected. If you have more than one port forward list, you can use the dropdown list to select the appropriate one. Finally, notice that the Automatically Download Applet option is selected by default. This means that once the SSL VPN user logins, the applet will start automatically.

The configuration to be sent to the router is as follows:

webvpn context WEBVPN
 port-forward PF_Servers
 local-port 20023 remote-server 1.1.1.1 remote-port 23 description "Telnet to RTR1"
 local-port 20022 remote-server 2.2.2.2 remote-port 22 description "SSH to RTR2"
 exit
 policy group policy_1
 port-forward PF_Servers auto-download
 exit
 exit

Now let’s test our configuration. As usual, we will login to the SSL VPN portal using https://22.22.22.22/.

Note: Using http:// instead of https:// will also work because HTTP port redirection is enabled.

After I connect successfully, Internet Explorer blocks the pop-up window, which is the Java Applet automatically starting.

Once I allow the pop-up, I get a series of security warnings concerning the certificate and also digital signature. I will just click on Yes/Run/OK for all those prompts.

Windows firewall also blocked Java from running, as shown below. I will unblock this because we need Java to run (it’s a Java applet after all):

Finally, we have the window displayed below. As long as this window is open (and we are connected to the SSL VPN portal), we will be able to reach those servers listed in the table.

Let’s now open the two sessions: the first will be telnet to 127.0.0.1 on port 20023 and the second will be SSH to 127.0.0.1 on port 20022.

What happens is that the one to RTR2 goes through but not the one to RTR1.

From the previous lab, I’m sure you already know that the problem is the zone-based firewall on RTR1. I will add the following configuration on RTR1 and then try again:

ip access-list extended TELNET_LOOPBACK0
 permit tcp any host 1.1.1.1 eq 23
class-map type inspect match-all CMAP_TELNET_LOOPBACK0
 match protocol tcp
 match access-group name TELNET_LOOPBACK0
policy-map type inspect ccp-permit
 class type inspect CMAP_TELNET_LOOPBACK0
 inspect

Great! Also notice that the Bytes In, Bytes Out, and Sockets fields in the application access window have increased.

When I close this window shown above, my SSH and Telnet sessions immediately stop responding and I eventually lose the connection. We can start it again from the SSL VPN portal by clicking on the Start button under to the Application Access section.

Summary

This brings us to the end of this lab, which looked at thin-client SSL VPN. We have seen how the thin-client feature allows remote SSL VPN users to access TCP-based services that operate on fixed ports such as Telnet and IMAP.

The last lab in this series will focus on the full client SSL VPN and I hope this entire series has been of benefit to you.

Further Reading

Thin-Client SSL VPN (WebVPN) IOS Configuration Example with SDM: http://www.cisco.com/c/en/us/support/docs/security/ssl-vpn-client/70664-IOSthinclient.html