Setup VNet-To-VNet VPN on Microsoft Azure - Part 2

In part 1, we set up VNet to VNet connection from West US to East US. In this part, I'm going to create 1 more VNet in North Europe and then set up the VPN from North Europe to West US. To set up multi-VNet connections, we cannot complete this action on Microsoft Azure Portal. We have to download and modify the current VNet configuration file and then upload the updated configuration file to Microsoft Azure.

Prerequisites

• The configuration computer is installed Microsoft Azure PowerShell module
• Make sure you set up "Setup VNet-To-VNet VPN on Microsoft Azure - Part 1" lab environment

Goals

• Create a new VNet named nelabvnet in North Europe region
• Create a new local network with the same name nelabvnet
• Create a dynamic routing gateway on nelabvnet
• wuslabvnet connected to 2 VNets (euslabvnet and nelabvnet)

Lab

First, we need to download the current VNet configuration file and then add the new virtual and local network into configuration file.

1. Launch "Azure PowerShell" as administrator on a workstation.

2. Connect to your Azure subscription by performing "Add-AzureAccount".

3. Perform "Get-AzureVNetConfig -ExportToFile C:\VNetConfig.xml" to export the VNet configuration to C:\VNetConfig.xml.

4. Open "VNetConfig.xml" in "Windows PowerShell ISE" as administrator and then focus on Local Network Sites first.

There are 2 local network sites under our vnet configuration. We need to add a new local network for North Europe region.

5. Copy from <LocalNetworkSite> to </LocalNetworkSite> and then paste it under </LocalNetworkSite> of wuslabvnet.

6. Change the name, AddressPrefix and VPNGatewayAddress to nelabvnet, 10.3.0.0/16 and 172.16.0.3.

The latest local network configuration will be the following.

Then, we need to add a new virtual network and update "Connect to local network" in this virtual network configuration file.

7. Copy from <VirtualNetworkSite> to </VirtualNetworkSite> and then paste it under </LocalNetworkSite> of wuslabvnet.

8. Change the name, Location, AddressPerfix and LocalNetworkSiteRef to the following.

name = nelabvnet

location = North Europe

AddressPrefix = 10.3.0.0/16

AddressPrefix = 10.3.0.0/19

AddressPrefix = 10.3.32.0/29

LocalNetworkSiteRef = wuslabvnet

9. Then, we need to add 1 more LocalNetworkSiteRef named nelabvnet under wuslabvnet.

Eventually, we have the following virtual network configuration.

10. Save the VNet configuration.

11. Back to Azure PowerShell console, perform "Set-AzureVNetConfig -ConfigurationPath C:\VNetConfig.xml" to update VNet configuration on Microsoft Azure.

Click to wuslabvnet virtual network, the portal will display the 2 virtual network connection.

  

However, we haven't created a gateway on nelabvnet and set up shared key for both VNets.

Click "Configure".

The Local Network option of wuslabvnet was configured to multiple. We cannot configure this on Microsoft Azure Portal.

12. Back to Azure PowerShell console, perform "New-AzureVNetGateway -VNet nelabvnet -GatewayType DynamicRouting -Verbose" to create a new dynamic gateway with dynamic routing for nelabvnet.

 Remark: It takes 15 - 30 minutes to create a gateway.

13. Perform "$GIP = (Get-AzureVNetGateway -VNetName nelabvnet).VIPAddress" to get the gateway IP address of nelabvnet and then save it to $GIP variable.

14. Perform "$xml = [xml](Get-Content C:\VNetConfig.xml)" to get the xml content and save it to $xml variable.

15. Perform "($xml.NetworkConfiguration.VirtualNetworkConfiguration.LocalNetworkSites.LocalNetworkSite | where name -eq nelabvnet).VPNGatewayAddress" to get the gateway IP address of nelabvnet in the vnet configuration file.

We entered a temp gateway IP address for nelabvnet local network in the configuration file. Now, we need to update the configuration file and then upload to Microsoft Azure to update the virtual network settings.

16. Perform "($xml.NetworkConfiguration.VirtualNetworkConfiguration.LocalNetworkSites.LocalNetworkSite | where name -eq nelabvnet).VPNGatewayAddress = $GIP" to update the IP address.

17. Perform "$xml.save("C:\VNetConfig.xml") to save the updated content into the virtual network configuration file.

18. Perform "Set-AzureVNetConfig -ConfigurationPath C:\VNetConfig.xml" to update virtual network configuration on Microsoft Azure.

19. Perform "$Gwkey = (Get-AzureVNetGateway -VNetName wuslabvnet -LocalNetworkSiteName euslabvnet).value" to get the current shared key between wuslabvnet and euslabvnet. Then, save it to $Gwkey variable.

Remark: Get-AzureVNetGateway can get the shared key and show it as clear text.

20. Perform "Set-AzureVNetGatewayKey -VNetName nelabvnet -LocalNetworkSiteName wuslabvnet -SharedKey $Gwkey" to setup VPN tunnel on nelabvnet.

21. Perform "Set-AzureVNetGatewayKey -VNetName wuslabvnet -LocalNetworkSiteName nelabvnet -SharedKey $Gwkey" to setup VPN tunnel on wuslabvnet.

Eventually, wuslabvnet connected to euslabvnet and nelabvnet.

Please note that virtual machines under wuslabvnet can communicate with euslabvnet and nelabvnet. However, virtual machines under euslabvnet and nelabvnet cannot communicate with each other because we didn't add "Local Network Site Ref" into VNet configuration file and configured shared key. To communicate between euslabvnet and nelabvnet, we updated the VNet configuration file and then upload to Microsoft Azure. After that, configure shared key on both sites. Eventually, virtual machines under euslabvnet and nelabvnet can communicate with each other.

Additional:
By default, the Azure Gateway SKU is Default.

It supports S2S VPN throughput to 80Mbps and 10 S2S VPN tunnels. It costs $0.036 US dollar per hour.

Except Default gateway SKU. Microsoft Azure provided High Performance one. It supports S2S VPN throughput to 200Mbps and 30 S2S VPN tunnels. It costs $0.49 US dollar per hour. To update the gateway SKU, we can perform "Resize-AzureVnetGateway -VNetName <virtual network name> -GatewaySKU HighPerformance".

Eventually, the virtual network was changed to High Performance.

Reference:

Connect Multiple On-premises Sites to a Virtual Network

Azure Virtual Network Gateway Improvements

Other parts in this series

Setup VNet-To-VNet VPN on Microsoft Azure - Part 1

This posting is provided “AS IS” with no warranties, and confers no rights!

Tracing group policy processing in Event Viewer by using Activity ID

Jeremy Moskowitz, an MVP of Group Policy, showed a demonstration to create a custom view in Event Viewer to trace Group Policy processing of domain group policy objects for a specific user or computer in Teched North America 2014. By default, events are under "Microsoft-Windows-GroupPolicy/Operational" saved all events related to group policy processing for all users and a computer account. It is difficult to trace Group Policy processing for a specific user or computer. To easily trace Group Policy processing for a specific user or computer, administrators have to find the "Activity ID" of a user or computer. 

To locate a suitable "Activity ID", we need to understand the behavior of  "Activity ID". When a user logs in or a computer updates group policy periodically, a user or a computer will generate a new "Activity ID". administrators should locate an "Activity ID" for troubleshooting.

Goals

• Locate "Activity ID" of a user or a computer.
• Create a custom view to trace Group Policy processing

Lab environment

• 1 computer is installed Windows 2012 R2 (Supported operating system: Windows Vista or later)

Lab

1. On a computer, log in as Administrator.

2. Launch "Event Viewer".

3. Navigate to "Applications and Services Logs > Microsoft > Windows > GroupPolicy > Operational".

4. Right-click "Operational", select "Filter Current Log".

5. On "Filter Current Log" window, next to "<All event IDs>", enter "4001", "4006".

6. Click "OK".
7. Select "Event ID 4001".

We can locate an "Activity id" of administrator. The "Activity id" will changed when the same user log on the same computer again. We should select the latest one to troubleshoot the group policy processing. Event ID 4001 is used to locate an "Activity id" of user accounts.

8. Click "Close".
9. Select "Event ID 4006".

Event ID 4006 is used to locate an "Activity id" of a computer account. "Activity id" will change when a computer update group policy objects.  We should select the latest one to troubleshoot the group policy processing.

10. Close "Close".
11. Copy the "Activity id" of administrator to a notepad.

12. Navigate and then right-click "Custom Views", select "Create Custom View".

13. On "Create Custom View", select "XML" tab.
14. Check "Edit query manually".

15. Click "Yes" to manually edit the query.

16. Microsoft provided the following XML code for us to paste it in this pane.

<QueryList><Query Id="0" Path="Application"><Select Path="Microsoft-Windows-GroupPolicy/Operational">*[System/Correlation/@ActivityID='{INSERT ACTIVITY ID HERE}']</Select></Query></QueryList>

Reference:
Troubleshooting Group Policy Using Event Logs

17. Copy the above code and then paste it into the XML pane.
18. Replace "INSERT ACTIVITY id HERE" to the "Activity ID" from a notepad.

19. Click "OK".
20. On "Save Filter to Custom View" window, next to "Name", enter "Administrator GPO tracing".

21. Click "OK".

As a result, all related events of administrator showed in "Administrator GPO tracing".

More information

Group Policy: Notes from the Field - Tips, Tricks, and Troubleshooting

This posting is provided “AS IS” with no warranties, and confers no rights!