site-to-site | Jaap Wesselius

In my previous blog I wrote about creating a virtual network in Microsoft Azure and a site-to-site VPN connection to connect your on-premises network to the virtual network in Azure. The next step is to create a Domain Controller and (optional) an Azure AD Connect server in Microsoft Azure.

On a Domain Controller on-premises, create a new site in Active Directory and a new subnet and assign it to the new site. In my environment, the new site is called ‘Azure’ and the new subnet is ‘172.16.1.0/24’ as shown in the following screenshot:

Adding a new VM to Azure is not too difficult, but you must be careful with change the network properties. Do not change the DNS setting on the NIC inside the VM, but change it on the properties of the networking interface object in Azure.

Open the properties of the Virtual Machine in Azure, scroll down to Networking (under Settings) and click on the Network Interface. Select DNS Servers (under Settings) and add the (AD Integrated) DNS server on-premises shown in the following screenshot:

It takes some time before the new settings are active. Once active, you should be able to resolve other machines on the on-premises network and more important, join the new VM to Active Directory. And once joined, install the ADDS components on the new VM and promote it to a new Domain Controller, running in Azure.

Another thing I have changed in Azure is the DNS setting of the virtual network. Open the virtual network properties and scroll down to DNS Servers (again under settings). Open the DNS servers properties, select the ‘custom’ radio button and add the IP address of the new Domain Controller (with Integrated DNS of course). All VM’s on this virtual network now use the new Domain Controller for name resolution.

For external recurring DNS queries, and the Azure forwarder with IP address 168.63.129.16 on the forwarders tab of the DNS server as shown in the following screenshot:

The next step is to create a VM that will host the Azure AD Connect server. It still is my test environment so VMs don’t have to be that big, so for the Azure AD Connect server I’m using the Standard DS1 v2 (1 vcpu, 3.5 GiB memory) as well. You can also install Azure AD Connect on the Domain Controller in Azure, but personally I’m not a big fan of installing other services on Domain Controllers.

Make sure the new VM is connected to the Virtual Network that was created earlier, it will automatically get an IP address in the correct range.

Once installed, logon to the new server, join it to the domain and reboot again, just you would do with a server on-premises.
Since we are working post migration to Exchange Online we do have an Azure AD Connect server running on-premises. Moving this server to Azure is just like upgrading an Azure AD Connect server. Export the configuration of the existing server to a JSON file, and import this JSON file using the Azure AD Connect setup application. I have blogged about this process in an earlier upgrade blog: https://jaapwesselius.com/2021/12/24/upgrade-azure-ad-connect-from-1-x-to-2-x/ but it’s similar to moving to Azure.

When using this method, the new server will automatically be in ‘staging mode’, so it will fill its database with information, but it won’t sync anything with Azure AD. When you are ready, set the old server in staging mode and get the new server out of staging mode. At this point you are synchronizing using Azure AD Connect in Azure instead of on-premises.

As an Exchange consultant I still do a lot of work with Exchange server on-premises, like migrations to Exchange 2019 and hybrid migrations to Exchange Online. In a typical Exchange hybrid environment 99% of all mailboxes are in Exchange Online, and only a handful of mailboxes are in Exchange on-premises. As a result, only one or two Exchange servers are left on-premises; for management purposes, for SMTP routing purposes and host these leftover mailboxes. A logical follow-up question is “why not put them in Azure?”.

Placing the last Exchange server in Azure can be costly, but a lot of customers are working hard to decommission their on-premises server room, so from that point of view it’s a valid question.

Before going into detail about this Exchange server in Azure, a couple of other things need to be in place:

Site-to-Site VPN connection between on-premises and Azure.
Domain Controller in Azure (optional: Azure AD Connect in Azure).
Exchange server in Azure.

These make a couple of interesting blogs 🙂

Site-to-Site VPN with Ubiquity EdgeRouter

The first step is to create a site-to-site VPN connection between the internal network and Microsoft Azure, and we begin with a virtual network in Microsoft Azure.

The internal network is 10.83.4.0/24 and the Azure Virtual Network is 172.16.0.0/22, separated in a gateway subnet (172.16.0.0/24) and a server network (172.16.1.0/24).

My configuration looks like this (but my external IP addresses are different):

These are the steps I executed in the Microsoft Azure Portal:

Create a new Azure Virtual Network:
- Name: ServerNetwork
- Address Space: 172.16.0.0/22
- Subnet name: Default
- Subnet Address Space: 172.16.1.0/24
- Resource Group: MyTestRG
Create a Gateway Subnet (under Virtual Networks, select Subnets and click +Gateway Subnet. The properties of the Gateway Subnet are automatically populated.
- Name: GatewaySubnet
- Address space: 172.16.0.0/24
Create a new Azure Virtual Network Gateway:
- Name: VirtualGateway
- Gateway type: VPN
- VPN type: Route-Based
- SKU: Basic
- Basic is using a dynamic external IP address. Static IP Address is only available in better (ie more expensive) versions. More info on https://learn.microsoft.com/en-us/azure/vpn-gateway/vpn-gateway-about-vpngateways
- Virtual Network: ServerNetwork
- Public IP Address: Create new during creation of VirtualGateway
- Public IP Name: ..cloudapp.azure.com
- Public IP Address SKU (dynamic)
- The creation of the VirtualGateway can take quite some time, so be patient…
Create a local network gateway
- Name: LocalGateway
- IP Address:
- Address Space: 10.83.4.0/24 (your own internal IP address space)
- Create the VPN Connection (under VirtualGateway  Connections)
- Name: IPsecER
- Connection type: Site-to-Site (IPSec)
- Virtual Network Gateway: VirtualGateway
- Local Network Gateway: LocalGateway
- Shared Key: <secret>

For testing purposes, I created a new Virtual Machine in Azure (Standard DS1 v2 (1 vcpu, 3.5 GiB memory). This is automatically connected to the newly created Virtual Network. Using the external IP address, you can use RDP for the initial connection. For security purposes, use the Network Security Group (NSG) to restrict RDP only to your own IP address. After connecting, enable the ‘File and Printer Shared (Echo request – ICMPv4-In) Inbound Rule in Windows Defender Firewall. This makes connectivity testing a lot easier.

The Ubiquite EdgeRouter supports site-to-site VPN solutions, including site-to-site to Microsoft Azure which is documented in the EdgeRouter Route Based Site-to-Site VPN to Azure article. Not all devices are supported by Microsoft as documented in the Microsoft article About VPN devices and IPsec/IKE parameters for Site-to-Site VPN Gateway connections. Keep in mind though that not tested by Microsoft means ‘not supported by Microsoft’ but that does not automatically include ‘does not work’. If the vendor (Ubiquity in my case) supports it, you’re good to go.

When the router is configured correctly the site-to-site connection is automatically setup and the VPN Connection status should change to ‘Connected’ as shown in the following screenshot:

At this point you should be able to ping the VM in Azure (that’s connected to the virtual network that we created earlier) from a machine in your local network and vice versa.

In my next blog I will discuss installing a Domain Controller in Azure.