J
JohnScott
I spent way too much time setting up a point-to-site VPN connection in Azure Government yesterday, so I figured I would do a quick blog post in the hopes this saves someone some time.
I typically setup a VPN connection between my on-prem environment to my sandbox in Azure to test network injected scenarios such as running applications on an App Service Environment, testing a SQL migration to an Azure SQL Managed Instance, etc. A point-to-site VPN is a very simple way to achieve this, but I had not yet deployed it to my government subscription. The pre-reqs are as follows:
There is a tutorial of the steps for creating these resources here.
I chose the VpnGw1 SKU for my Virtual Network Gateway (VNG) as this is just for testing and I do not require a great deal of bandwidth or number of connections, but you can size your VNG to your needs.
The next step is to setup the point-to-site. To do this, you open the Virtual Network Gateway and choose the "Point-to-site configuration" blade. The setup here is fairly simple - we add an address pool (I typically use an RFC-1918 space that does not conflict with my VNet space), the type of tunnel (we're using OpenVPN as we're doing Microsoft Entra ID authentication), the type of Authentication (which is still branded "Azure Active Directory"), and the public IP you want to use.
The next step is to add the Azure Active Directory (Microsoft Entra ID) values. Being in Azure Government, we need to consider that our endpoints are different than those in the commercial environment. The document here has a list of steps to do this, including the mapping between Azure Commercial and Azure Government endpoints. The endpoint mapping is as follows:
Wait. Why doesn't the issuer change? Shouldn't that go to a government endpoint too? Well, the short answer is "no." I was severely overthinking this and tried to guess at this endpoint, putting in "login.microsoftonline.us" in place of the "sts.windows.net" value, but I got the following error when I tried to connect:
[Error] Dialing VPN connection ase-vnet, Status = Server did not respond properly to VPN Control Packets. Session State: Key Material sent
That didn't help me too much so, after spending an embarrassing amount of time digging through Microsoft Entra ID, I finally had the idea to actually grab a JWT token from my tenant and inspect it. You can grab a token (I'll write a future article on how to do this) and decode it in a tool like jwt.ms. Sure enough, looking at the token, the issuer is still https://sts.windows.net/{TenantID}. Once I corrected that, my VPN client was able to connect.
There are many places in our learn.microsoft.com documentation describing the point-to-site VPN configuration process, but I feel that this documentation best describes the process for clouds other than Azure Commercial, such as Azure Government. It will walk you through authorizing the Azure VPN Application (which requires the Global administrator role in Entra ID), and how to configure the Azure VPN Client as well. Just don't do as I did and overthink the Issuer!
Continue reading...
I typically setup a VPN connection between my on-prem environment to my sandbox in Azure to test network injected scenarios such as running applications on an App Service Environment, testing a SQL migration to an Azure SQL Managed Instance, etc. A point-to-site VPN is a very simple way to achieve this, but I had not yet deployed it to my government subscription. The pre-reqs are as follows:
- Create a virtual network
- Create a GatewaySubnet on the virtual network
- Create a Virtual Network Gateway
There is a tutorial of the steps for creating these resources here.
I chose the VpnGw1 SKU for my Virtual Network Gateway (VNG) as this is just for testing and I do not require a great deal of bandwidth or number of connections, but you can size your VNG to your needs.
The next step is to setup the point-to-site. To do this, you open the Virtual Network Gateway and choose the "Point-to-site configuration" blade. The setup here is fairly simple - we add an address pool (I typically use an RFC-1918 space that does not conflict with my VNet space), the type of tunnel (we're using OpenVPN as we're doing Microsoft Entra ID authentication), the type of Authentication (which is still branded "Azure Active Directory"), and the public IP you want to use.
The next step is to add the Azure Active Directory (Microsoft Entra ID) values. Being in Azure Government, we need to consider that our endpoints are different than those in the commercial environment. The document here has a list of steps to do this, including the mapping between Azure Commercial and Azure Government endpoints. The endpoint mapping is as follows:
- Tenant ID
- Audience
- 41b23e61-6c1e-4545-b367-cd054e0ed4b4 -> 51bb15d4-3a4f-4ebf-9dca-40096fe32426
- Issuer
Wait. Why doesn't the issuer change? Shouldn't that go to a government endpoint too? Well, the short answer is "no." I was severely overthinking this and tried to guess at this endpoint, putting in "login.microsoftonline.us" in place of the "sts.windows.net" value, but I got the following error when I tried to connect:
[Error] Dialing VPN connection ase-vnet, Status = Server did not respond properly to VPN Control Packets. Session State: Key Material sent
That didn't help me too much so, after spending an embarrassing amount of time digging through Microsoft Entra ID, I finally had the idea to actually grab a JWT token from my tenant and inspect it. You can grab a token (I'll write a future article on how to do this) and decode it in a tool like jwt.ms. Sure enough, looking at the token, the issuer is still https://sts.windows.net/{TenantID}. Once I corrected that, my VPN client was able to connect.
There are many places in our learn.microsoft.com documentation describing the point-to-site VPN configuration process, but I feel that this documentation best describes the process for clouds other than Azure Commercial, such as Azure Government. It will walk you through authorizing the Azure VPN Application (which requires the Global administrator role in Entra ID), and how to configure the Azure VPN Client as well. Just don't do as I did and overthink the Issuer!
Continue reading...