Windows Desktop Sharing API

I have integrated Windows Desktop Sharing API in our application.

We're able to remote share a session via a LAN or VPN but we're having not much luck with purely Internet.
A viewer PC in the Internet cannot share a sharer PC in the Internet but if these PCs are connected via a VPN connection then it does work.

is this a limitation with Windows Desktop Sharing API on connecting two PCs via purely Internet.

Thanks in advance.
Who is Participating?
CoralonConnect With a Mentor Commented:
Ok, based on what I can make out of that string, you just need to translate the NAT address.  You'll need to detect your external IP address.  The key will be determining which end you need to translate.  My guess will be that the client end of connection (not the initiator) will need to provide the correct external address.  

As I mentioned before, RDS/TS provides a utility that assigns an external address.  Your clients will need to be able to provide that information, and they will have to open the ports on their firewall to handle the routing on that side.  

Your other options are to create a gateway piece that runs from the client side to handle that NAT traffic, or you can use some sort of broker product.  

The way WebEx and GoToMeeting work is that they have a broker and both the client & server piece of the connection establish connections to the broker, and then the broker connects the 2 streams together.  This lets both clients establish outbound connections, which *generally* eliminates the issue with firewall, since most firewalls allow direct outbound connections without too many restrictions. But, that is also where most companies rely on SSL, since SSL outbound is virtually never restricted.    

So, ultimately, you will need to establish and handle the connections outside of the sharing API - you have to get that tunnel/translation established first.  

The last option I can think of would be to use some sort of SSH tunnel between the client & server, and again, you'll have to make sure that the intervening firewall handles it correctly.

I wish I could offer you a better option, but with the solid identification of the problem going across the internet, those are your only options that I can think of.  

It sounds like a network routing issue.  Does your application take a lot of these internet issues into account?
* Latency
* Bandwidth
* Proxies

When you put up a VPN, you are eliminating most of these.  My guess for you -- I'd be looking at the NAT or Proxy issues.  Most users are behind a NAT, and many ISPs use non-routable addresses on their own internal routing. (I've done a number of traceroutes over the years that traverse an ISP network that uses non-routable addresses while they are in the ISP's network, but are NAT'd back gain when they hit the public sides.

carlostriassiAuthor Commented:
Thank you for comments.

Sorry for not responding quickly.

These are good points and we had emphasize those areas of NAT using Microsoft API techniques, latency when viewer fails to connect sharer and then doing a reverse connect that worked for us, we have tested using proxies.

How do I go about that to trace this issue if it is NAT and ISP related.

A hint, a few times this one remote PC I was able to share my session. Interesting enough it had work after I used logmein to verify that another product would work. It had seemed has done something to make our remote share worked but can't pin point what did it.

Cloud Class® Course: Certified Penetration Testing

This CPTE Certified Penetration Testing Engineer course covers everything you need to know about becoming a Certified Penetration Testing Engineer. Career Path: Professional roles include Ethical Hackers, Security Consultants, System Administrators, and Chief Security Officers.

You'll want to collect network traces on both ends and start digging into the packets.  (Typically WireShark these days :-)

Now, if I am reading this correctly, you tested the same machine with LogMeIn.  LogMeIn runs over SSL, so NAT's become generally transparent, since the inbetween routers can't open the SSL stream, all they can do is wrap their own data around it, and then peel off their own layers.  

Are you using SSL for your product?

carlostriassiAuthor Commented:
Thanks for your response.

We're going to use SSL on our product in a few months.

Microsoft claims the following from this blog 

a) Connectivity: Windows Desktop Sharing does support connectivity to intelligent appliances, wireless devices and PC's in uPnP framework and also teredo tunneling to provide connectivity to IPV6 machines behind IPV4 NAT's.
b) Reverse Connect: It is an interesting feature, where sharer can connect to the viewer if viewer cannot reach the sharer via direct connect. For example, the viewer may not be able to connect to the sharer because of network address translation (NAT)

I have tested and our reverse connect has worked on VPN connection and we did notice an expected delay but it worked.

Would SSL work under Microsoft Rdpencom.dll technology using Remote Desktop Sharing API?

That helps give me a picture of what you are working on.  Correct me if I am wrong, but you are looking at some sort of alternate to RDP utilizing that framework on the system.  

Now, given that, I'd almost guarantee your issue is going to be handling the NAT.  RDP & ICA (Citrix) both have capabilities to handle NAT.  There is a utility in the RDS/TS hosts called AltAddr that is used for NAT.  It tells the system what the outside ip address of the connection is so that when the connection is established through a NAT, the host will respond with the outside address of the connection instead of the inside.  I haven't used it in over a decade, but it is still available.  The way RDS & ICA handle it these days is through the use of a gateway server that handles that NAT translation for the packets.

Assuming all of this is correct, you'll want to look into how you are handling NAT.  

carlostriassiAuthor Commented:
Remote sharing API is an utility for meetings instead of using remote desktop. Basically the person that hosted the meeting invites as many user to share his/her screen.

The person who share his/her screen called the sharer creates an invitation that all invitees would use to connect to the sharer.

The invitation format created by one of Microsoft APIs is as follows, this invitation is prvided to all invitees.

<E><A KH="j5jT32dNuQjj6o++32paqNiwDVc=" ID="WinPresenter"/><C><T ID="1" SID="761889938"><L P="52002" N="fe80::840e:653f:c2c2:859e%12"/><L P="52003" N="fe80::4cce:9b4a:92e7:72a6%11"/><L P="52004" N="fe80::5efe:"/><L P="52005" N="fe80::5efe:"/><L P="52006" N=""/><L P="52007" N=""/><L P="52008" N=""/></T></C></E>

Connectionstring API that uses invitation ticket input generated by the sharer.

IRDPSRAPIInvitation::ConnectionString property

HRESULT get_ConnectionString(
  [out]  BSTR *pbstrVal

i don't know how much control we can interject in this API since I was expecting Microsoft to handle the NAT under the hood.

I don't know any way around this.

carlostriassiAuthor Commented:
Thanks for you explanation to make very clear what needs to be done.

I guess two thing I need to do:

1. Handle NAT Traffic via gateways, a broker product or SSH Tunnel.
2. replace the NAT IP address to the external address in the invitation ticket so that the client or viewer is going to connect to the sharer screen.

On #1, what would suggest handling NAT traffic based on our solution that is a peer-to-peer remote sharing between viewer and sharer. What URL link would you suggest to start reading on.

Unfortunately, I can't help you with that one.  I'm not a heavy developer...   You'll have to look into ways to wrap your protocol on the internet, and then have your gateway strip that extra layer.  

Good luck!

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.