Introduction
This article describes a simple and time-effective way to quickly establish a reliable "temporary" connection to a secured Windows-based environment that has Internet connection with unrestricted port 443 (TCP) using an undocumented functionality of Microsoft Azure.
The presented functionality works at least on the following Windows editions:
- Windows 2008 R2 SP1
- Windows 7 SP1
Of course, I have first contacted Microsoft Security Response Center to elaborate if they see any potential vulnerability in the observed behavior. At the state on 25.8.2016 when I publish this article their answer was negative so I feel confident to share this information with developers.
The technique described below is neither obvious nor standard. It perfectly works at the state on 25.8.2016, but Microsoft may close the identified reverse connection opportunity later if they eventually find it insecure.
Remember to get permission from your customer before you open any extra connection in any environment. Any potential misuse of this information is at your own risk and responsibility.
Typical use cases
a. You have a home PC. You want to connect to your running home PC from whatever location via RDP. You don’t want to pay for a dedicated static IP address at home location or conduct any time-consuming negotiations with a representative of your ISP.
b. You are a developer in the customer’s project. You are waiting for many days while the customer grants you a secure access to some QA or DEV environment while your colleague already has a connection. As usual, your colleague cannot share VPN connection credentials with you during working hours because only one person can be connected using them at the same time.
c. You are a solution architect. You found a component of an outsourced developer did not work in QA / DEV. A developer has to overview the problem blindly; of course, wasting your time over numerous Skype sessions/emails. This would be significantly more time effective to connect this person temporarily to QA / DEV machine for a quick live review, but a duration of bureaucratic routines to open extra connections crosses out this idea.
Prerequisites
1. Any Azure subscription.
· “Free Trial” subscription can be acquired on the official site by the URL https://azure.microsoft.com/en-us/free/.
2. Azure virtual machine (Azure VM), Windows-based. It can be of any size. For example, extra small (A0, 0.75 GB) is quite sufficient. Similar VM can be provisioned in ~10 minutes.
· The official guide can be found by the URL https://azure.microsoft.com/en-us/documentation/articles/virtual-machines-windows-hero-tutorial/
3. Established Azure VNET with configured Point-to-Site VPN; it takes ~30-45 min. to configure it from the scratch.
· The official complete configuration guide can be found by the URL https://azure.microsoft.com/en-us/documentation/articles/vpn-gateway-point-to-site-create/.
4. Self-signed Client Certificate (SSL) for that VPN.
· Refer to the “Section 2 - Generate and upload certificates” of the official guide.
5. Azure VPN client package; this is a downloaded executable of tiny size (~200 kb).
· Refer to the “Section 4 - Configure your VPN client” of the official guide.
Requirements for the target environment
The target environment you wish to connect to must have Internet connection and unrestricted access via port 443 (TCP, at least outbound, better both ways).
Requirements for a connecting person
The person you are connecting to the target environment should have Internet connection and any RDP client for Windows.
The idea behind the solution
There is an undocumented feature of Point-to-Site VPN client for Azure that allows connecting back to a machine that initiated this VPN connection in certain conditions. More details can be found in my previous article.
The solution
1. Connect to your target environment (Home PC, QA) under any available account using an RDP session
· For example, you can ask your colleague to connect to QA / DEV on your behalf (refer to the use cases above).
2. Install Client Certificate and Azure VPN client inside the established RDP session to the target environment.
- Both can be downloaded or made from Azure if needed.
- Note you do not need to install anything on the physical machine of the target environment. Use namely the established RDP session to the target environment to install them.
3. Initiate and open Point-to-Site VPN connection inside the RDP session to the target environment (~30 seconds.).
- You can find a private IP address issued by Azure VPN to the established client using "ipconfig".
- Alternatively, this IP is visible in the connection properties on Azure portal.
- Keep this Point-to-Site VPN connection open; in my tests, it fairly survived for many days.
4. Connect to your Azure VM over the internet using some local account of that VM, open an RDP session from its desktop to the RDP session on target environment by private IP from p.3, enter credentials, and keep this RDP window open inside your Azure VM.
- Note your local RDP session can be disconnected (replaced with the one that you have just established from Azure VM).
5. Ask the person to connect to your Azure VM under the same local account that you used to connect to Azure VM. See p.4. The person will open your RDP session and get access to the RDP windows inside.
As a result, the person can start effectively working in the target environment. You don’t have to share any extra credentials to that person except for some local account to connect to Azure VM.
That's all.
P.S. Please remember you cannot use reverse connection if you make it directly to a physical or virtual client machine. Attempts to connect will just close your "Point-to-Site" VPN session in this case.
Instead, you should connect back to the VPN session established from inside a local RDP connection to your physical or virtual machine. And you should not log-off your RDP session for the same reason; just close its window when completed (it keeps running in the background and can be reused later).
