I had been recently evaluating network capabilities of Microsoft Azure and found an undocumented reverse connection option that looked interesting to me.
It looks like there is a feature (or bug) in the configuration of "Point-to-Site" VPN client of Microsoft Azure. This feature allows me to connect back from any Windows Virtual Machine running in my Microsoft Azure subscription to local VPN clients
via RDP session.
I describe my findings below.
Short description
In usual conditions a "Point-to-Site" VPN connection drops in the case when you try to connect back to physical or virtual client machine that initiated this VPN connection, but as I found it survives if the initial VPN connection was done inside
the RDP session established to the physical or virtual machine.
Question
Can anyone explain technical reasons of the observed behavior: P2S VPN connection drops in the case when you try to connect back to a physical or virtual machine but survives in case of existing RDP from that machine?
The matter is I can see hidden security risks for my customers in case of misusing this backdoor by IT staff. So I want to understand the core reasons why it happens.
Initial conditions
Assume you have a Virtual Network ("VNET") in your Azure subscription with configured "Point-to-Site" VPN.
You have a Virtual Machine running Windows ("Azure VM"); it has Remote Desktop client ("RDP").
You also have a physical or virtual local machine with <g class="gr_ gr_126 gr-alert gr_gramm gr_disable_anim_appear Grammar multiReplace" data-gr-id="126" id="126">installed</g> "Point-to-Site" VPN client
for Microsoft Azure. Let's name it "Local PC #1".
You establish a Remote Desktop session from "Local PC #1" to "Azure VM"; let's name this connection "RDP Azure VM". You initiate and open a "Point-to-Site" VPN connection from "Local PC #1" to your "VNET"
as usually.
As a result, you can connect to your resources hosted in Azure subscription using private IP addresses of "VNET".
Attempt to connect back #1
If you try to connect back from "RDP Azure VM" to your "Local PC #1" using RDP client of "RDP Azure VM" and IP address issued to "Point-to-Site" VPN client of "Local PC #1" the connection fails *. It happens
because your "Point-to-Site" VPN session immediately disconnects as it should be (no shared connection allowed).
* You can easily find this IP address in a number of ways, for example:
- On the VPN client machine using "<g class="gr_ gr_162 gr-alert gr_spell gr_disable_anim_appear ContextualSpelling ins-del multiReplace" data-gr-id="162" id="162">ipconfig</g>" and exploring the section "PPP
adapter <name of your VNET>".
- On the portal.azure.com under All resources > (your VPN gateway) > Point-to-site configuration > Allocated IP addresses (for Resource model VNET).
- On the portal.azure.com under All resources > (your VNET) > VPN connections > (n) clients > IP addresses (for Classic model VNET).
- A simple Powershell script that just iterates a potential set of IP addresses of your VPN pool accessible from "Azure VM".
Special conditions
Assume you have a second local machine, let's name it "Local PC #2", and you establish a Remote Desktop session from "Local PC #2" to "Local PC #1"; let's name this connection "Local RDP PC #1".
After that, you install "Point-to-Site" VPN client for Microsoft Azure inside the RDP connection "Local RDP PC #1".
You initiate and open a "Point-to-Site" VPN connection from "Local RDP to PC #1" to your "VNET" as usually.
As a result, you can connect from "Local RDP PC #1" to your resources hosted in Azure subscription using private IP addresses of "VNET".
Now please find and remember the IP address issued to "Point-to-Site" VPN client of "Local RDP PC #1".
Let's name it "Local RDP IP of VPN Client".
- Refer to the previous chapter to find this IP address.
- Note this IP address issued to "Local RDP PC #1" is different from the one issued to "Local PC #1" because technically there are two different VPN clients who established connections.
Attempt to connect back #2
If you try to connect back from "RDP Azure VM" to your "Local RDP PC #1" using RDP client of "RDP Azure VM" and IP address issued to Point-to-Site VPN client of "Local RDP PC #1" ("Local RDP IP of VPN Client",
see above) the connection somehow succeeds while there is still no shared connection allowed. As a result, you can access any resources of "Local PC #1" and other machines of LAN from "RDP Azure VM" using RDP connection established to "Local
RDP PC #1".
As you can see there is an unexpected and undocumented difference in reverse connection behavior between "Attempt to connect back #1" and "Attempt to connect back #2".
Tested environments
Reverse connection has succeeded at least in the following client VPN environments of mine:
- Windows 7
- Windows Server 2008 R2, Standard Edition
- Windows 8.1