This blog post is written as a guide for peering Lab Services with an on-premise network. Every network architecture is different and so this post is not intended as a detailed step-by-step instructional document. Rather, the intention of this document is to give guidance for the general steps and mention any possible issues that may arise with common network architectures.
The document discusses connecting to an on-premise network. It is assumed that on-premise network has a network gateway to which a VPN tunnel (site-to-site or ExpressRoute) may be connected. Details regarding how to setup an on-premise network will not be covered in this document. It is important to know the following information before proceeding.
- What type of VPN tunnel is supported to the on-premise network? It should be either site-to-site or ExpressRoute. ExpressRoute is a private connection between the Azure datacenters infrastructure on the Customer’s premises. A site-to-site VPN gateway connection used to connect to your on-premises network over IPsec. NOTE: If the connection type is ExpressRoute, you will need someone with the appropriate permissions to create a connection to the ExpressRoute gateway.
- The public ip address of the vpn gateway for the on-premise network.
- Shared key for the connection from the hub gateway to the on-premise gateway. A shared key is like a password to ensure the connection is expected.
The diagram below shows the architecture of the solution that will be used. There is an on-premise network with a vpn gateway. Since virtual networks created for a classroom lab cannot be connected directly to an on-premise network, we will create a virtual network in the as the lab account. This virtual network will be connected via a VPN tunnel to the on-premise network. It will also be peered to the virtual network created in the Azure Lab Services subscription for your classroom lab. The virtual network in the same subscription as the lab account is the glue that makes the scenario work.
A couple notes before we get started:
- The lab account resource and the Azure virtual network to be peered must be in the same region.
- The virtual network should be in the same subscription. If this is not possible, as might be the case when using Express Route, the lab account will need to be peered to a vnet in the same subscription and then a vnet-to-vnet connection made with BGP enabled between the peered vnet and the ExpressRoute hub vnet.
Create your Lab Account
Follow the instructions at how to manage lab accounts to create your lab account. Don’t worry about peering vnets yet. We need to setup our vnet first.
Creating the VNet and Gateway in Your Subscription
- Create a resource group to hold the virtual network and related resources.
- Name: hub-rg.
- Create a virtual network in the hub-rg resource group.
- Name: hub-vnet
- Subscription: Same subscription as your lab account.
- Location: Same location as your lab account.
- Address Range: Select ip range that does not overlap with any existing ip ranges for the on-premise network. This address range will specify the address range for all classroom lab virtual machines. We will use 10.1.0.0/16. Remember this range for later.
- NOTE: It is extremely important that the vnet be created in the same subscription and location as your lab account. You will not see this virtual network as an option in the peered network setting for the lab account otherwise.
- Create a gateway subnet in hub-vnet. This is required to create a vpn gateway.
- Open the virtual network in the Azure Portal and click ‘Add gateway subnet’.
- Choose an ip range that is within the larger vnet range that doesn’t overlap any existing subnets. We will use 10.1.255.0/27.
- NOTE: It is recommended to use a /27 or /28 range for your gateway subnet.
- Create a virtual network gateway instance.
- NOTE: This step can take up to 45 minutes to complete.
- In the Azure search for ‘Virtual Network Gateway’ when adding a new resource
- Subscription: same as lab account
- Name: hub-vpn-gateway
- Region: Same as lab account and vnet
- Gateway type: VPN or ExpressRoute as appropriate
- VPN type: Leave a Route-base unless on-premise network architecture requires policy-based.
- WARNING: If using a policy-based vpn, you must update the address spaces on both sides of the tunnel simultaneously. Otherwise, you could cause a disruption in the tunnel.
- Sku: Sku options are listed in https://docs.microsoft.com/en-us/azure/vpn-gateway/vpn-gateway-about-vpn-gateway-settings#gwsku. We will use Generation 1, VpnGw1.
- Virtual network: hub-vnet
- Public ip address: create a new public ip called hub-gw-pip
- NOTE: If ‘enable active-active mode’ or ‘configure BGP ASN’ need to be enabled, contact consult your IT department. Both settings are more advanced and outside the scope of this document.
- Wait for the virtual network gateway instance creation to complete. You will need to know the address of the public ip (hub-gw-pip) before continuing.
- Create a local network gateway
- Name: hub-local-gw
- IP address: onpremise ip address (This is the public ip of the onpremise-vpn-gateway instance.)
- Address space: Address space for onpremise-vnet.
Create Connection between Hub Gateway and On-Premise Gateway
Connections must be created in both directions to be complete. First, let’s start with the hub gateway to on-prem gateway connection.
- Open hub-vnet-gateway in the Azure Portal.
- Choose Connections.
- Click Add
- Name: HubtoOnPrem
- Connection type: IPSec for site-to-site connections. Choose ExpressRoute for that type of connection.
- Second virtual network gateway: choose hub-local-gw
- Shared key (PSK): shared keyed for connection to the onpremise gateway. This should be a value
- IKE Protocol: leave at IKEV2. (Route based)
- WARNING: IKEV1 (policy based) is the older version of the protocol. Changes to one side of ‘PolicyBased’ or ‘RouteBased with PolicyBasedTrafficSelectors’ can cause issues with the tunnel. Update both sides together.
Second, create the connection from the on-prem network to the Azure virtual network. Once that hub to on-prem connection is made, the on-prem to hub connection must be made by the person or team maintaining the on-premise network. The same shared key must be used.
Each row in the connections blade for virtual network can be clicked to open the connection details blade. The status will tell you if the bi-direction connection is complete or not.
Peer hub vnet to Lab Services Lab Account
Peer the lab account to the hub vnet by following instructions at https://docs.microsoft.com/en-us/azure/lab-services/classroom-labs/how-to-connect-peer-virtual-netwo.... Remember the hub-vnet must be in the same subscription and region as the lab account to be seen in the drop down.
IMPORTANT: The vnet peering on the lab account must be done before any labs are created. Previously created template machines or student virtual machines are not updated.
IMPORTANT: Also, it is important to set an address range for the new lab to use. If not specified Lab Services will default to something like 10.x.0.0/16. If you used any of the default ranges making the hub vnet, the lab services lab vnets could overlap the hub vnet’s address space causing issues.
Make sure to specify an address range large enough to hold all the lab you wish to create. A subnet with a /23 subnet is created for each lab. (/23 CIDR range creates a maximum of 512 addresses.) For example, a /21 address range will be large enough to create 4 labs for that lab account. Azure side adds these addresses to the total vnet address spaces for the vnet gateway. The onpremises vpn must include the lab vnet address space as well as the hub vnet address space for traffic to flow over the peering branches.
Conclusion
You are now ready to start creating labs. Make sure to check any NSG settings on the on-premise network to all traffic from the Lab Services hosted VMs to the on-premise server.
If you want to test that a lab vm can connect to an onpremise machine, it is common to use ping. Ping is a tool available on both Windows and Linux that sends messages using the ICMP. By default, Azure VMs block the ICMP. To use ping, you will need to add a firewall rule on the Azure VM to allow ping, update any NSG rules blocking ICMP and possibly update the firewall rules on the destination resource in the on-premise environment.
Alternately, if the resource you want to reach is available on a different port, you can use the Test-Connection PowerShell cmdlet.
Test-netconnection <ip> -Port <portnumber>