What is the exact set up to port forward RDP over WebVPN on ASA?

Answered Question
Aug 12th, 2010

I've seen discussion elsewhere of using the ASA's WebVPN, and then using mstsc on Windows to send a normal RDP session through the VPN connection. Success is reported, but the recipe isn't spelled out. I get the notion that it should involve setting up port forwarding on the ASA. Then if for example the port forwarded is 50001, then this on the client system would connect through:

mstsc /v:127.0.0.1:50001

That's suggested at http://microsoft-server-operating-systems.hostweb.com/TopicMessages/microsoft.public.windows.terminal_services/781703/1/Default.aspx - there are similar partial reports elsewhere, such as at http://hardforum.com/showpost.php?p=1035146809&postcount=5.

In our case the administration of the Cisco is in other hands - we're in a hosted situation behind an ASA dedicated to our use. What exactly do we need to request of them to get regular Windows RDP working in this way? We've been trying the Java and ActiveX plugins, but those are limited in various ways and don't work consistently on all client systems, so we'd like to try using MS's RDP client instead. We're not in a situation to require our users to install VPN client software, so we need a way that works with the WebVPN. It's encouraging other people have this working. But we can't yet find where anyone's published a complete recipe in enough detail to pass on exact instructions to our third-party ASA admins.

Is port forwarding the key to this? Or would a "smart tunnel" be an option? Thanks for any advice.

I have this problem too.
0 votes
Correct Answer by Marcin Latosiewicz about 6 years 5 months ago

Whit,

Let's take a step back.

Port forwarding works very much like forwarding with SSH. You specify that certain remote host/port will be available via this port locally (and yes you connect via localhost:localport), little java applet does the rest.

Now smart tunnel (for programs) it's a trickier beast, it's basically causing all instances of a program to establish sockets via tunnel.
Result? You specify you want to connect to something on the remote side as though the program would be remote. Not sure if it makes sense

There's also smart tunneling of bookrmaks and homepages but that's a completly different matter.

If you're looking for something simple but maybe not so ... straight forward to use port forwarding should be just fine.

Marcin

P.S.

I'm not familiar with limitations of running terminal services in a smart tunnel (not to say that there are non).

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
Loading.
whitblauvelt Thu, 08/12/2010 - 15:59

Thanks for the quit response! I'm not clear if tunneling does what we need. Does smart tunneling allow running the mstsc/rdp client on the local user's system, to connect to the desktop on the remote system the far side of the ASA? If so, we're going to need to know two things: 1. Precisely what to ask the ASA admins to do, to tunnel to TCP port 3389 on the remote system, and 2. Precisely how to start mstsc to connect over that tunnel.

We might be just as happy with either port forwarding or tunneling. But since we don't have admin rights ourselves to the ASA, and since the guys who do need to have things carefully spelled out, being pointed to the fine manual, which lacks a clear example of the entire arrangement we're seeking, is helpful but not quite enough.

With port forwarding, if we know how to request the ASA be configured for it, then we just point mstsc to the localhost and the port forwarded, right?

With tunneling, if we know how to request the ASA be configured for it, where do we point mstsc? To the public IP on the Cisco of the remote system? Will that automatically route through the WebVPN tunnel then?

whitblauvelt Thu, 08/12/2010 - 16:04

The more I read about smart tunneling the more confused I am about it. Does it support RDP at all, from a client program on the client's local system? Or is a way of running a remote application as if it were local? The docs talk about setting up exact application or process names, making it sound like these are applications on the remote system that then get run on the client system's desktop. If this is how it works, this could actually be useful to us, as a future project.

But right now what we need is a way to run RDP in the traditional way, so it will work just as RDP does when used directly, but in this case sending it through the WebVPN connection for added security.

Correct Answer
Marcin Latosiewicz Thu, 08/12/2010 - 23:50

Whit,

Let's take a step back.

Port forwarding works very much like forwarding with SSH. You specify that certain remote host/port will be available via this port locally (and yes you connect via localhost:localport), little java applet does the rest.

Now smart tunnel (for programs) it's a trickier beast, it's basically causing all instances of a program to establish sockets via tunnel.
Result? You specify you want to connect to something on the remote side as though the program would be remote. Not sure if it makes sense

There's also smart tunneling of bookrmaks and homepages but that's a completly different matter.

If you're looking for something simple but maybe not so ... straight forward to use port forwarding should be just fine.

Marcin

P.S.

I'm not familiar with limitations of running terminal services in a smart tunnel (not to say that there are non).

whitblauvelt Fri, 08/13/2010 - 05:25

Marcin,

Thanks for clarifying smart tunneling. The docs talk about setting it up for specific programs, but aren't clear about what to expect from it, or what the relation between the client and remote system is. I've found a mention elsewhere of someone getting RDP to work through an ASA's smart tunnel. And several mentions of getting it to work through an ASA's port forwarding. If the smart tunnel requires that every possible RDP client be identified and the smart tunnel configured for it prior to use - am I understanding this right that it would? - then we might want port forwarding instead so it's not bound to use of a specific client. The smart tunnel is based on the client process or program name rather than the port or protocol, right? So there's no ASA setting to smart tunnel all RDP requests, but only those from a known client?

If we did set it up as a smart tunnel, bound to the specific RDP client, is the RDP client then running as if it were local on the remote end, or is it running in the normal way where its local on the client system? (Maybe I'm not making sense, still trying to get the concept right.) Do they behave differently via port forwarding versus smart tunneling in regards to printing from RDP at the client end, or copying a file from the remote to the client end? Would printing and/or file copying in a smart tunnel context require smart tunnels specific to the programs being invoked for those? We have users who need to both print and copy files.

Using the ActiveX RDP plugins it's possible to get printing working (it requires an extra flag in invoking the plugin, plus the right printer drivers installed on the remote) but there's evidently no way to alter the ASA's JavaScript to add a line there that would permit invoking a third-party dll that supports file copying (which works on a non-Cisco WebVPN product we use elsewhere). The ASA's JavaScript is flashed to a location where there's no tool offerred to update it. That's part of what has us looking at RDP through port forwarding or smart tunneling instead. Once we have it working, we'll have to get printing and copying working too. That's the next step.

RDP can be so useful, it's curious it's not more thoroughly supported yet. It would be nice if there was a thorough article reviewing the different ways to accomplish it through a Cisco. Thanks again for your help in getting the concepts clear.

Best,

Whit

Marcin Latosiewicz Fri, 08/13/2010 - 06:47

Whit,

With smart tunneling or port forward enabled you are seen on the remote site as the ASA. ASA is the proxy.

Indeed it's true:

- Port forwarding requires explicit defintion of all remote hosts you will want to connect.

- smart tunneling makes all connections via network go via wevpn tunnel to remote side.

regarding printing:

via RDP:

http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&bugId=CSCsi20860

I have to admit, I have not played with priting over RDP, but it MAY be just a question of adding additional applications to smart tunnel lists like you mentioned.

As for missing functionalities that function elsewhere, I'm not the best person to say this to. Talk to your account team on Cisco side, ask to have those features intergated. They can do money talk with business unit and opern product enhancement requests. Enhanamcent requests filed by TAC have usually little to no meaning. Such is a big corporate environment, money talks (probably it's the only thing)

Marcin

whitblauvelt Fri, 08/13/2010 - 07:25

Marcin,

You've been a great help. Apologies for asking one more question. Since we don't own the ASA in question here - we're paying high rent on it at a hosting provider who exclusively runs Ciscos - I can't follow the BugToolKit link about printing. What's the gist of it? We're paying more money renting this ASA over a year than if we'd bought several, and we had the hosting provider buy it from you for our exclusive use, specifically because we needed to provision WebVPN on it to support RDP, and they wouldn't set that up for us on a shared router. But it doesn't look like that's enough for us to get in to read the bug reports. Which is part of why I'm looking to this forum for advice.

Guess we'd need to buy a Cisco in our own name to get the account to allow us to more directly work with Cisco to get support for the Cisco we've already, at a step removed, paid for. Not of course anything you're involved in setting up that way I'm sure. Other questions we've had go through our hosting provider, which then get sent on to your TAC, which basically comes back around with about as much information as is in your online manuals, which if it were enough would have answered our questions before we forwarded them through. It would be great if the BugToolKit reports were available to customers of customers somehow.

Best,

Whit

Marcin Latosiewicz Fri, 08/13/2010 - 07:38

Whit,

I'm not that part of Cisco to know exactly but I believe there's some sort of shared support contracts that would probably get you where you want to see.

The defect is actually an enahancement request anyway it's for local printing via RDP plugin as and it's "closed" with comment of "done" but no information about integrated version, but it's an internal bug . Long story short a mess ;-)

If you want me to add to the confusion you can try tsweb + smart-tunnel (bookrmark version) .

I've done some searches and it seem that priting via RDP and smart tunnel should work but no actual case studies :{

Marcin

whitblauvelt Fri, 08/13/2010 - 14:27

Just want to note that port forwarding for RDP works well. There was a small confusion on which port number goes where because by "Local" Cisco means on the system remote from the Cisco - the remote client. By "Remote" Cisco means the machine directly behind the Cisco - the local server. The Cisco uses the terms from the POV of the client rather than it's own POV or that of the system behind it.The admin simply set this up through the GUI, so it was in that context that the terms were confusing. Didn't take long to spot the mistake though.

File copying works fine across systems through Windows Explorer, as long as the option has been set to allow access to local drives - which then show up at the remote system. Haven't tested printing yet.

Doesn't do single sign on, but in other respects looks much better than using the ActiveX or Java RDP plugin.

whitblauvelt Mon, 08/16/2010 - 14:28

Printing seems not to work. At least the remote desktop can't see a printer on the local machine being connected from. Is there something extra to do to enable it?

Actions

This Discussion