Home NewsX Setting up a Point-to-Site VPN connection in Azure Government (the quick version)

Setting up a Point-to-Site VPN connection in Azure Government (the quick version)

by info.odysseyx@gmail.com
0 comment 2 views


I spent way too much time yesterday setting up branch office VPN connectivity in Azure Government, so I thought I’d write a quick blog post in the hopes that it might save someone some time.

I typically test network injection scenarios, such as running applications in an App Service Environment or testing SQL migrations to Azure SQL Managed Instance by establishing a VPN connection between my on-premises environment and a sandbox in Azure. A branch-to-site VPN is a very simple way to achieve this, but I have not yet deployed it to a government subscription. The prerequisites are:

  1. Create a virtual network
  2. Create a GatewaySubnet in your virtual network.
  3. Create a virtual network gateway

There is a tutorial on the steps to create these resources. here.

I chose the VpnGw1 SKU for my Virtual Network Gateway (VNG). This is for testing purposes only and doesn’t require a lot of bandwidth or connections, but you can adjust the VNG size to suit your needs.

The next step is to set up your Point-to-Site. To do this, open your virtual network gateway and select the “Point-to-Site Configuration” blade. The setup here is very simple. Add an address pool (usually using RFC-1918 space that doesn’t conflict with your VNet space), a tunnel type (we’re doing Microsoft Entra ID authentication, so we’ll use OpenVPN), an authentication type (it’s still branded as “Azure Active Directory”), and the public IPs you want to use.

P2S-Config1.png

The next step is to add the Azure Active Directory (Microsoft Entra ID) value. Since you are in Azure Government, you need to take into account that the endpoints are different from those in a commercial environment. Documentation here Here is a list of steps to do this, including mapping between Azure Commercial and Azure Government endpoints. The endpoint mappings are as follows:

  • Tenant ID
  • audience
    • 41b23e61-6c1e-4545-b367-cd054e0ed4b4 -> 51bb15d4-3a4f-4ebf-9dca-40096fe32426
  • publisher

Wait. Why wouldn’t the issuer change? Shouldn’t it go to the government endpoint? Well, the short answer is “no.” I took this seriously and tried to guess this endpoint by replacing the “sts.windows.net” value with “login.microsoftonline.us”, but when I tried to connect, I got the following error:
[Error] VPN connection ase-vnet dialing, status = The server did not properly respond to VPN control packets. Session state: Key material sent.

That didn’t help me much, so after spending a ton of time digging through the Microsoft Entra IDs, I finally came up with the idea of ​​actually getting the JWT token from the tenant and inspecting it. Once I got the token (I’ll write a future article on how to do this), I could decode it in a tool like this: jwt.ms. If you look at the token, the issuer is still https://sts.windows.net/{tenantID}. After I fixed that, the VPN client was able to connect.

Download

There are many places in the learn.microsoft.com documentation that explain the process of configuring a point-to-point VPN, but I think it goes like this: This document Best describes the process for clouds like Azure Government, not Azure Commercial. Walks you through how to authorize an Azure VPN application (requires Global Admin role in Entra ID) and how to configure an Azure VPN client. Don’t think too much about the issuer like I did!





Source link

You may also like

Leave a Comment

Our Company

Welcome to OdysseyX, your one-stop destination for the latest news and opportunities across various domains.

Newsletter

Subscribe my Newsletter for new blog posts, tips & new photos. Let's stay updated!

Laest News

@2024 – All Right Reserved. Designed and Developed by OdysseyX