Monday, March 17, 2008

Remote assistance on Vista computers behind a NAT device

Remote assistance and NAT

Remote assistance is a handy feature, and I have used it on more than one occasion to help out other friends. However, this particular friend was using a Network Address Translation (NAT) firewall. Since your typical ISP only assigns you a single IP address, if you have more than one computer, then you will need multiple IP addresses. NAT allows you to create an entire network of bogus IP addresses. When someone needs to access the Internet, the request is sent to the NAT firewall, and it makes the request to the Web site on behalf of the user. In doing so, the request appears to have come from the network’s one legitimate IP address. When the Web site replies to the request, the reply is sent to the NAT firewall. The NAT firewall receives the request and then forwards it to the appropriate bogus IP address on the private network.

So why is using NAT such a big problem for someone who is trying to provide or receive remote assistance? Well, there are a couple of reasons. First, think about the name NAT Firewall. While a NAT Firewall box does provide NAT services, it is first and foremost a firewall. Firewalls are designed to block any unauthorized types of packets. This includes packets used for remote assistance.

Secondly, even if the person’s NAT firewall were configured to allow remote assistance related traffic, the entire concept of NAT causes some problems. For instance, let’s say that the computer that a home-based user needs help with has an IP address of 192.168.1.6. If the user were to send you a remote assistance invitation, it would attempt to connect your computer to 192.168.1.6. Unfortunately, this is a bogus IP address that exists only on the user’s private network. The address is not accessible from the Internet, which means that you can’t attach to the machine through a remote assistance session.

Tweaking NAT

Although Windows doesn’t natively support NAT traversal for remote assistance sessions, there is a way that you can provide remote assistance to someone who is behind a NAT firewall. However, doing so requires a little bit of tweaking by your user. If the user isn’t very knowledgeable about computers, the necessary tweaking might be over their heads and you might find yourself having to provide remote assistance in person after all.
The process begins in the usual way. The user who needs remote assistance would click the Start button, select the Help and Support Option, and would then click the Invite A Friend To Connect To Your Computer With Remote Assistance. The user who needs help would then follow the prompts and send you a request for remote assistance, either through e-mail or through an instant message.

Although the invitation usually arrives in the form of an e-Mail or instant message, the invitation itself consists of an XML file. Figure A shows what the file looks like. If you look closely at Figure A, you’ll notice that there is an IP address embedded in the XML file. In this particular case, the IP address is 147.100.100.27. This is a bogus address that exists only on my private network. If this invitation had been sent to me by a friend, the invitation would not work because it addresses a machine that is behind a NAT firewall.

If I want to help the user who sent the invitation, the first thing that I would have to do is to modify the invitation. I would need to change the bogus IP address to the user’s one legitimate IP address. If the user doesn’t know what his legitimate IP address is, he should be able to get it by looking at the configuration section of the NAT firewall. Unfortunately, I can’t give you exact instructions because every firewall’s user interface is a little bit different.

Adjust port forwarding


Changing the address found in the remote assistance invitation is only half of the tweak. Remember that using this address will only get you as far as the NAT box, as it won’t forward remote assistance traffic on to the user's computer. Furthermore, the NAT box is still set to block remote assistance traffic.

These problems can be addressed through port forwarding. If you look at Figure A, you will notice that the highlighted IP address is immediately followed by a colon and by the number 3389. This number is the port that remote assistance traffic is set to use. Therefore, to get remote assistance traffic to the PC that users need help with, they must enable port forwarding on the NAT firewall and must forward any traffic destined for port number 3389 to the bogus address on their private network.

Again, the configuration procedure will be a little bit different depending on what brand of NAT firewall is being used. However, you can see an example of remote assistance port forwarding in Figure B. The settings shown in Figure B tell the NAT firewall that if any traffic comes in on the legitimate IP address through port 3389, the traffic should be redirected to 147.100.100.27 on the private network.

One PC limit

The only problem with this configuration is that it only allows one PC on the entire private network to receive remote assistance. If another user were to require remote assistance with a different PC, the NAT firewall’s port forwarding option would need to be reconfigured. Nonetheless, you still won't have to drive to the user's location to help troubleshoot a PC when using port forwarding.

In short, here is how you need to do for remote assistance to be working from a computer originated from a computer inside a LAN
  1. if it's a vista machine, configure port forward for port 51930 for both TCP & UPD
  2. for the xml attachment received by recipient, need to change the content of xml file, the RCTICKET attribute, change the internal IP of the orginate local IP address to it internet IP

note:

  1. remote assistance can only allow the other user to see the machine which originate the communicate and have no control of the machine, just wonder what good it is to use remote assistance
  2. for XP machine, the port which need to forward might be 3389, just check the attachment file received in the email and you will know.

No comments: