So far we played with clientLESS access to WebVPN. The major drawback of this method is that too few protocols are supported. The list is really short: HTTP, HTTPS, FTP and CIFS. If we need another protocol, well – tough luck. To solve this and other issues, we can use thin client or thick client options.
With this thin client approach we have these options:
- Port forward
- Smart tunnels
Plugins are small Java applets that we upload or import to our ASA appliance. When we do so, the ASA will place them in a special folder on the flash and made protocols implemented by these applets available in the SSL portal. The good thing about these applets is that they are pretty easy to set up and are extremely easy to use. However, there are only a small number of them available on Cisco site. These include VNC, ICA, RDP, SSH and TELNET protocols. There are maybe other protocol applets, but they are not tested and supported by Cisco. Let’s see how easy it is to set these up.
First, we visit Cisco site and download the applets. We need valid CCO to access a download page. From there we can download plugins we need. The applets are in the form of JAR files. After downloading, we should place applets on some kind of server accessible by the ASA. Let’s say a TFTP server. Now we download and import those plugins:
import webvpn plug-in protocol vnc tftp://x.y.z.w/ASAPLUGINS/vnc-plugin.111018.jar
import webvpn plug-in protocol rdp tftp://x.y.z.w/ASAPLUGINS/rdp-plugin.120424.jar
import webvpn plug-in protocol ssh,telnet tftp://x.y.z.w/ASAPLUGINS/ssh-plugin.111006.jar
With these three commands we downloaded and imported until now non supported protocols: VNC, RDP, SSH and TELNET. Now if we log in to our SSL portal, here is what we would see:
Piece od cake! Does it work? Sure it does!
This is a Telnet applet within our WebVPN browser session. Same goes with other protocols.
This is another way of implementing a thin client. We would use this one if we needed some protocol not supported with plugins, for instance Lotus notes or Microsoft Outlook. The only good thing here is that we can use protocols not supported by clientless type of access. There are some serious limitations, though:
- We cannot use protocols that dynamically negotiate ports to use
- Only TCP protocol based applications are supported
- Only a few protocols are tested and supported by Cisco
- There are more steps involved in configuring port forward
- Users may find port forward tough to understand and use
Let’s enable very same protocols like in previous chapter, but this time using port forward. First a short explanation on how port forward works. When we set a port forward on an ASA box, when a user connects he or she will have the option to start applications. When they do, a Java applet will start. This applet will download from an ASA to which local ports it should bind and to what remote ports it should forward requests than comes to local ports. For example, we could say that in order for user to connect to remote SMTP server 192.168.0.1/25 he or she should set up a SMTP client to use a 127.0.0.1/10025 as a SMTP server. Ok, let’s do that…
First we create a port forward list:
Now when a user that belongs to DirekcijaIT logs in, he/she will be presented with the following window:
In order to connect to remote TELNET server on 10.x.y.121 a user has to connect to 127.0.0.1/10023. Likewise, to connect to remote SSH server, a user is required to make a connection to 127.0.0.1/10022.
We could, of course use a hostnames instead of IP addresses:
This time we did not specify “auto-start” option, but instead just enabled port forward named GUI_APPS. This means that user will have to manually start Java applet by clicking “Application Access” on the left hand side in the SSL portal, and then “Start Applications” button in the middle of the windows. Then they will see:
And this was produced by:
Now user would use a name of a server instead of its IP address. There is one thing worth mentioning when using hostnames: Java applet changes local hosts file, like so:
When a user connects to putninalog:5900, he/she will actually connect to 127.0.0.2 which is the address on which Java applet listens for connections and redirects them to real server putninalog:5900 across the ASA.
At the same time it makes a copy to a file hosts.webvpn. In order for Java applet to correctly restore the original file, users should be instructed to close the applet right way, by clicking a close button on the top right corner. Otherwise, hosts file will remain changed after SSL session is over, which can cause unwanted results.
Smart tunnels is the way of proxying Winsock-2 TCP applications through the ASA. Client uses Active-X control or Java applet which is downloaded from the ASA and then executed.
We could make smart tunnel applet runs automatically after logon with the keyword “auto-start” like with port forward, or make users click a “Start Smart Tunnel” button under a “Application Access” pane:
Configuration is straight forward:
We created smart-tunnel list called STUNNEL_1 with two applications: telnet.exe and putty.exe. When a users starts either of them by typing their names, all traffic from within those applications will be redirected across the ASA. IMPORTANT: do not type those commands from within a command prompt, because that way the command that applet would see would be cmd.exe, not a telnet.exe or putty.exe. Start them from GUI or from Run option directly.
Major drawback of smart tunnels is that they are supported on only limited number of operating systems and only 32-bit versions with ASA image 8.2 and earlier. With ASA 8.3 and later, there is a support for 64-bit operating systems. We can only use TCP applications. The good thing is that we don’t have to be admins in order to use smart tunnels.
Next time a big thing: thick client, aka AnyConnect!