Forwarding an RDP (or SSH) session into an isolated vApp
Isolated networks are good for testing; however, getting stuff in or out is hard. The following section shows how to make it easier. I call it "hole-in-the-Fence".
Getting ready
You need a fully deployed vApp with an internal vApp Network and at least one VM (preferably two) in it. You can use the Deploying a vApp with vApp router recipe in this chapter to get started. However, you will need to connect a Direct Organization Network to the vApp so that you can test this configuration using your desktop. To add a single VM to the vApp, have a look at the Adding a VM to a vApp recipe in Chapter 3, Better vApps.
How to do it...
- Go into your deployed vApp by double-clicking on it.
- Click on Networking.
- Right-click on the vApp Network (not the Organization Network) and choose Configure Services.
- Click on Firewall. You should see the following screen:
- Select the first (and only) rule and then click on Delete.
- Make sure that the default action option is set to Deny.
- Click on Add... to add a new rule:
- Enter the following settings:
- Click on OK to add the new firewall rule.
- Now click on NAT.
- Select the NAT type as Port Forwarding and acknowledge the warning.
- Enable IP Masquerade should be selected, and if the vApp is already deployed, you will see the IP of the external interface next to Router external IP.
- Click on Add... to add a new rule and perform the following:
- Choose the External Port value as 3389 (or 22 for SSH).
- Set the Forward Port value to 3389 (or 22 for SSH).
- Choose a VM and click on OK to close the window:
- The setup is now finished. Click on OK to close the window. The following screenshot shows the correct NAT settings:
- The vApp Network now appears in a yellow color, meaning that it has changed. Click on Apply to commit the changes.
- After the changes have been deployed, we can now start configuring the VMs.
- Log into the OS of your VMs using the vCloud Console.
- Enable RDP in Windows or SSH in Linux.
- Test the setting by using RDP or SSH from the secondary VM in the same vApp to log into the primary one.
- Now that we are sure that RDP or SSH works, we can test from the outside. From your desktop, connect to the Router external IP that you found in step 11 (in my example, 172.16.1.100). It might take longer than usual to get connected but this should now work.
How it works...
Basically, what we did is port forwarded one TCP port through the vApp router firewall. We also made sure that all other traffic won't pass the firewall. We have basically punched a hole in the wall. As the firewall keeps the state of the connections, it knows to let the return traffic through, but nothing else. The following diagram shows the setup we have created:
So we have now gotten a connection to a VM inside and we can use a remote screen. What's the big deal? We could do the same without that much trouble using the vCloud Remote Console. However, the vCloud Remote Console uses Flash and only runs as fast as your desktop. I have had users that have complained that their VMs were running slow; however, it was the Flash console that ran slow, not the VMs.
The other reason why RDP/SSH is better is that not only can we use the remote screen but also use the file transfer feature in RDP, or SCP/SFTP in Linux, as they all use the same port. You might need to switch on the file transfer in RDP, if this is the case, the following screenshot shows how to enable file transfer with RDP:
There's more…
We can expand on this basic building block to build more complex solutions.
Creating multiple forwards
So we have punched a hole in the wall and we can get one RDP/SSH session through to one VM, but how do we get RDP/SSH to the other VMs?
The answer is surprisingly easy. We don't use TCP 3389 and 22; we use different ports and forward them to each VM on the correct port. The only thing you need to know about the vApp router (Edge) is that the firewall will receive the communication first, then it will redirect it to the NAT to be forwarded to the VM (also called postrouting in network terminology). Therefore, we have to create one firewall rule and one port forwarding rule for each VM. Make sure you use ports that are not used by other protocols and that these ports are routed between your desktop and the vApp Router. For more information, refer to http://en.wikipedia.org/wiki/List_of_TCP_and_UDP_port_numbers.
You can also apply the same principle to an Edge and create port forwarding into isolated Organization Networks using the following values:
To connect to a VM using a nonstandard RDP or SSH port just type in the port as shown in the following screenshots:
Logging network traffic
You can also log the network traffic of any of the vApp router firewall rules you implement by checking the checkbox Log network traffic for firewall rule. All traffic will be automatically forwarded to the Syslog server you have configured with vCloud. See the See also section.
Other ideas
You can use the same method for other purposes. Instead of forwarding an RDP/SSH connection to the vApp, you could allow a single connection from a specific VM on a specific port to a specific IP outside. This can, for example, be used to connect NFS or iSCSI from outside to the VM. However, you need to make sure you secure the firewall rules and don't let any other traffic out.
See also
For configuring a Syslog server, please refer to the Troubleshooting vCloud Router traffic and Setting up and using vSphere Syslog Collector recipes in Chapter 8, Troubleshooting vCloud.