• Scenario 1: Hybrid connectivity with Azure VPN Gateway
• Scenario 2: Hybrid connectivity with Azure VPN Gateway & Traffic Inspection with Azure Firewall
• Scenario 3: Hybrid Connectivity with Azure VPN Gateway, second level peered networks & full traffic inspection with Azure Firewall

At the previews posts, we covered the basics of routing traffic from/to on-premises, inspecting all traffic through Azure Firewall, and configuring the DNS for accessing the Private Endpoints. In this scenario, I am experimenting with connectivity between on-premises, the Hub & Spoke networks and a second level peered network (a network that is peered behind the Spoke network).

Recap of Scenario 1 & 2: We have a Hub network, two Spoke networks and an IPSec VPN connection with my on-premises network. We established routing all traffic through the Azure Firewall for inspection & configured DNS for accessing the Private Endpoint from on-premises & all Azure VNets.

In the third scenario, I am adding a new Spoke VNet, the “Azure 2” peered with my hub, and a third VNet, the “Azure 3” that is only peered with the “Azure 2” VNet. To enable connectivity between the “Azure 3” VNet and the rest of the networks, including the on-premises, we need a router at the “Azure 2” VNet. This can be an NVA or Azure Firewall. In my case, I added an Azure Firewall. The Azure Firewall of “Azure 2” VNet has the private IP: 192.168.200.64.

• Azure 3 VNet, VM Subnet Route Table:
  • 10.0.0.0/16 NH 192.168.200.68
  • 192.168.0.0/20 NH 192.168.200.68
  • 192.168.4.0/24 NH 192.168.200.68
  • 192.168.5.0/24 NH 192.168.200.68
  • 192.168.200.0/28 NH 192.168.200.68

• Azure 2 VNet, AzureFirewallSubnet:
  • 10.0.0.0/0 NH Internet
  • 10.0.0.0/16 NH 192.168.2.4
  • 192.168.0.0/20 NH 192.168.2.4
  • 192.168.4.0/24 NH 192.168.2.4
  • 192.168.5.0/24 NH 192.168.2.4

• Azure 2 VNet, VM Subnet:
  • 10.0.0.0/16 NH 192.168.200.68
  • 192.168.4.0/24 NH 192.168.200.68
  • 192.168.5.0/24 NH 192.168.200.68
  • 192.168.0.0/20 NH 192.168.200.68
  • 10.100.0.0/16 NH 192.168.200.64

• Azure Hub VNet, AzureFirewallSubet:
  • 10.0.0.0/0 NH Internet
  • 192.168.200.0/28 NH 192.168.200.68
  • 10.100.0.0/16 NH 192.168.200.68
• Azure Hub VNet, VM Subnet:
  • 10.0.0.0/16 NH 192.168.2.4
  • 192.168.4.0/24 NH 192.168.2.4
  • 192.168.5.0/24 NH 192.168.2.4
  • 192.168.4.4/32 NH 192.168.2.4
  • 192.168.200.0/24 NH 192.168.2.4
  • 10.100.0.0/16 NH 192.168.2.4
• Azure Hub VNet, GatewaySubnet:
  • 192.168.0.0/24 NH 192.168.2.4
  • 192.168.4.0/24 NH 192.168.2.4
  • 192.168.5.0/24 NH 192.168.2.4
  • 192.168.4.4/32 NH 192.168.2.4
  • 192.168.200.0/24 NH 192.168.2.4
  • 10.100.0.0/16 NH 192.168.2.4
• Spoke 2 VNet, VM Subnet:
  • 10.0.0.0/16 NH 192.168.2.4
  • 192.168.4.0/24 NH 192.168.2.4
  • 192.168.0.0/24 NH 192.168.2.4
  • 192.168.200.0/24 NH 192.168.2.4

Routing Example

Let’s describe a packet’s journey. The On-premises Server X (10.0.2.10) makes sends a packet to 10.100.0.4. 1st hop the packet goes to the default gateway, reaching the on-premises VPN device, in our case the RRAS. The RRAS has a custom route for 10.100.0.0/16 and forwards the packet to the VPN interface. The packet reaches the Azure VPN Gateway The Azure VPN Gateway has a custom route for 10.100.0.0/16 and forwards the packet to the HUB Azure Firewall, 192.168.2.4. The HUB Azure Firewall has a custom route for 10.100.0.0/16 and forwards the packet to the “Azure 2” Azure Firewall, 192.168.200.68. The “Azure 2” Azure Firewall does not have a custom route, but it has a route for 10.100.0.0/16 that is automatically populated by the VNet peering. The Azure FIrewall knows to forward the packet through the VNet peering and reaches the destination.

You can find more commends and tests in the below diagram with the whole solution.

Diagram: (Click here to download a high-resolution SVG image)

References:
Azure Routing Experiences | Scenario 1 – Apostolidis Cloud Corner
Azure Routing Experiences | Scenario 2 – Apostolidis Cloud Corner
Use Azure Firewall to inspect traffic destined to a private endpoint – Azure Private Link | Microsoft Docs
Azure Private Endpoint DNS configuration | Microsoft Docs
What is a virtual network link subresource of Azure DNS private zones | Microsoft Docs
Azure Firewall DNS Proxy details | Microsoft Docs
Create, change, or delete an Azure route table | Microsoft Docs

Pantelis Apostolidis

Pantelis Apostolidis is a Sr. Specialist, Azure at Microsoft and a former Microsoft Azure MVP. For the last 20 years, Pantelis has been involved to major cloud projects in Greece and abroad, helping companies to adopt and deploy cloud technologies, driving business value. He is entitled to a lot of Microsoft Expert Certifications, demonstrating his proven experience in delivering high quality solutions. He is an author, blogger and he is acting as a spokesperson for conferences, workshops and webinars. He is also an active member of several communities as a moderator in azureheads.gr and autoexec.gr. Follow him on Twitter @papostolidis.

www.cloudcorner.gr

The post Azure Routing Experiences | Scenario 3 appeared first on Apostolidis Cloud Corner.

• Scenario 1: Hybrid connectivity with Azure VPN Gateway
• Scenario 2: Hybrid connectivity with Azure VPN Gateway & Traffic Inspection with Azure Firewall
• Scenario 3: Hybrid Connectivity with Azure VPN Gateway, second level peered networks & full traffic inspection with Azure Firewall

This scenario shares the same topology as Azure Routing Experiences | Scenario 1 with some changes in order to route all traffic through the Azure Firewall. This will allow us to have full control & inspection of all traffic from/to on-premises and all Azure traffic from/to all VNets. To achieve this we need some Route Table configuration.

At first, to control the traffic from the on-premises network, we need to add a Route Table to the GatewaySubnet to route all traffic through the Azure Firewall. 192.168.0.0/24, 192.168.4.0/24 & 192.168.5.0/24 Next Hop: 192.168.2.4. Now if we try to access the Storage Account, we will realize that we are still going directly from the VPN Gateway to the Storage account, (10.0.1.4 -> AzureGW -> 192.168.4.4). This happens because the Private Endpoint services populate a /32 route to the VNet and all peered VNets. The effective routes of the VPN Gateway now have our custom 192.168.4.0/24 -> 192.168.2.4 route but they also have the 192.168.4.4/32 -> Virtual Network route that is created by the Private Endpoint Service. Since it is a more specific route, it takes priority. The only way to bypass this in a hybrid scenario like this is to create a /32 route “192.168.4.4/32 Next Hop 192.168.2.4”. You can check more scenarios here. Now the GatewaySubnet Route Table is:
192.168.0.0/24 Next Hop 192.168.2.4
192.168.4.0/24 Next Hop 192.168.2.4
192.168.5.0/24 Next Hop 192.168.2.4
192.168.4.4/32 Next Hop 192.168.2.4

After this Route Table is applied to the GatewaySubnet, we can inspect the traffic coming from on-premises through the Azure Firewall logs. The /32 Route for the Private Endpoint must be applied to all Route Tables that are on VNets that are directly peered with the Private Endpoint VNet. I also added the /32 route to the VMSubnet. The Spoke2 subnet does NOT need to have the /32 route, since it is not directly peered with the Private Endpoint VNet. To access the Private Endpoint we added the /32 route to all Hub VNets, the GatewaySubnet, and the VMs subnet. The /32 route is not needed only services at the Spoke2 subnet, that is not directly peered with the Spoke1 subnet that has the Private Endpoint. And this is why the /32 route is created together with the Private Endpoint and it is populated to all peered subnets.

About the DNS configuration, as discussed in Scenario 1, to access Azure PaaS services, like the Storage, the Azure SQL, the Web App, we need to use the URI, since they don’t listen to the IP. Since we have Azure Firewall at the configuration, and I have enabled the Azure Firewall DNS Proxy feature to use it as a Conditional Forwarder for the on-premises DNS, we can also use it for the Azure estate. I changed the DNS of the Spoke2 VNet to the Azure Firewall, 192.168.2.4 to be able to resolve the Storage account’s Private IP. Linking all Private DNS zones to Azure Firewall’s VNet, usually the Hub VNet, we can use Azure Firewall as our DNS server to all VNets.

DNS & Routing example

DNS: The on-premises Server X, 10.0.2.10, makes a request to https://azappsa.blob.core.windows.net. At first, it asks the DNS to resolve the URL to an IP. The DNS has a conditional forwarder about blob.core.windows.net, and asks the Azure Firewall, 192.168.2.4. Azure Firewall has a linked Private DNS zone that has a host record for azappsa.blob.core.windows.net and it resolves to 192.168.4.4. This information routes back to Server X. Now Server X knows that the IP address of azappsa.blob.core.windows.net is 192.168.4.4.

Routing: To go to 192.168.4.4 first it asks its Default Gateway, in our case the RRAS. The RRAS has a custom route for 192.168.0.0/16 and forwards the packet to the VPN interface. The packet reaches the Azure VPN Gateway. The Azure VPN Gateway has a custom route for 192.168.4.4/32 and sends the packet to the Azure Firewall, 192.168.2.4. The Azure Firewall does not have a custom route, but it has a route that is automatically populated by the VNet peering with address 192.168.4.4/32. The Azure Firewall knows to forward the packet through the VNet peering and reaches the destination.

You can find more commends and test at the diagram below:

References:
Azure Routing Experiences | Scenario 1 – Apostolidis Cloud Corner
Use Azure Firewall to inspect traffic destined to a private endpoint – Azure Private Link | Microsoft Docs
Azure Private Endpoint DNS configuration | Microsoft Docs
What is a virtual network link subresource of Azure DNS private zones | Microsoft Docs
Azure Firewall DNS Proxy details | Microsoft Docs
Create, change, or delete an Azure route table | Microsoft Docs

Pantelis Apostolidis

Pantelis Apostolidis is a Sr. Specialist, Azure at Microsoft and a former Microsoft Azure MVP. For the last 20 years, Pantelis has been involved to major cloud projects in Greece and abroad, helping companies to adopt and deploy cloud technologies, driving business value. He is entitled to a lot of Microsoft Expert Certifications, demonstrating his proven experience in delivering high quality solutions. He is an author, blogger and he is acting as a spokesperson for conferences, workshops and webinars. He is also an active member of several communities as a moderator in azureheads.gr and autoexec.gr. Follow him on Twitter @papostolidis.

www.cloudcorner.gr

The post Azure Routing Experiences | Scenario 2 appeared first on Apostolidis Cloud Corner.

• Scenario 1: Hybrid connectivity with Azure VPN Gateway
• Scenario 2: Hybrid connectivity with Azure VPN Gateway & Traffic Inspection with Azure Firewall
• Scenario 3: Hybrid Connectivity with Azure VPN Gateway, second level peered networks & full traffic inspection with Azure Firewall

Scenario 1: Hybrid connectivity through Azure VPN gateway

At the start, I created the on-premises network, using a RRAS (Windows Server 2019 with Routing & Remote Access) to act as the router/VPN device and a Server with DNS service. The Azure estate has three VNets, in a hub & spoke topology. One HUB and two Spokes, connected with the HUB with VNet peering. There is no peering between the spokes. My Azure HUB network has three subnets, one has a VPN Gateway, the second has a VM, and the third has an Azure Firewall. In this first scenario, the Azure Firewall acts only as a DNS Proxy. It is not included in routing.

• On-premises network: 10.0.0.0/16
• HUB VNet Address Space: 192.168.0.0/22
• HUB GatewaySubnet: 192.168.1.0/24
• HUB VMSubnet: 192.168.0.0/24
• HUB Firewall Subnet: 192.168.2.0/24
• Spoke1 (storage account): 192.168.4.0/24
• Spoke2 (VM): 192.168.5.0/24

The first spoke has a Private Link to my storage account. The second spoke has a VM.. Azure VPN Gateway knows all routes of its VNet, the peered VNets & the routes propagated from the VPN connection. From on-premises, we can reach all resources using the VPN connection interface ( in RRAS I added a custom route “192.168.0.0 255.255.0.0 interface:AzureGW”)

From the VM of the HUB VNet (192.168.0.4), in order to be able to reach the on-premises network, we need a custom route, since the on-premises network is not populated to the VNet. I created a Route Table, with route “10.0.0.0/16 Next Hop: Virtual Network Gateway” attached to the VM Subnet.

To access the Private Endpoint of the Storage account we need some more resources & configuration. The storage account, as all PaaS services (like Web App & Azure SQL) responds only to URI and not to IP. Since we have connected a Private Endpoint to the Storage Account, the Public Access is blocked. So, in order to connect to the storage account, we need the aprostore.file.core.windows.net to translate to the private IP of the storage account, the 192.168.4.4. The proper way to achieve this is by using DNS.

First, we need to create a Private DNS zone and link it to the HUB VNET. For accessing blob storage we need a Private DNS zone with the name privatelink.blob.core.windows.net, for the file we need privatelink.file.core.windows.net. More services here. Then add the Storage Account Private Endpoint record to the Private DNS Zone. Now there is an A record azappsa with IP 192.168.4.4. Now, all Azure resources at the linked VNet, the HUB, are able to resolve the DNS records of the Private DNS Zone. We cannot resolve the records of the Azure Private DNS Zone from on-premises. To do so, we need a DNS server on Azure, to use as a conditional forwarder. This can be a Windows or Linux VM with DNS services or in my case, the Azure FIrewall with the DNS proxy enabled (I will use the whole functionality of the firewall to my next scenarios). I enabled the DNS Proxy on Azure, using default Azure DNS, and I added a conditional forwarding at the on-premises DNS “blob.core.windows.net -> 192.168.2.4” and “file.core.windows.net -> 192.168.2.44”. Now, I can successfully resolve the private IP of the storage account using its name, and be able to connect to it to both blob and to files with SMB access.

From the VM of the Spoke2 VNet (192.168.5.4), in order to be able to reach the on-premises network, we need a custom route, since the on-premises network is not populated to the VNet. I created a Route Table, with route “10.0.0.0/16 Next Hop: Virtual Network Gateway” attached to the VM Subnet. I added a second route “192.168.4.0/24 Next Hop: Virtual Network Gateway” & changed the VNet DNS to 192.168.2.4 (the Azure Firewall) to be able to access the Spoke1 VNet for storage access.

DNS & Routing example

DNS: The on-premises Server X, 10.0.2.10, makes a request to https://azappsa.blob.core.windows.net. At first, it asks the DNS to resolve the URL to an IP. The DNS has a conditional forwarder about blob.core.windows.net, and asks the Azure Firewall, 192.168.2.4. Azure Firewall has a linked Private DNS zone that has a host record for azappsa.blob.core.windows.net and it resolves to 192.168.4.4. This information routes back to Server X. Now Server X knows that the IP address of azappsa.blob.core.windows.net is 192.168.4.4.

Routing: To go to 192.168.4.4 first it asks its Default Gateway, in our case the RRAS. The RRAS has a custom route for 192.168.0.0/16 and forwards the packet to the VPN interface. The packet reaches the Azure VPN Gateway. The Azure VPN Gateway has a custom route for 192.168.0.0/24 BUT it also has a route for 192.168.4.4/32 that is automatically populated by the VNet peering. The /32 route is more specific than the /24 route, so the VPN Gateway forwards the packet directly to the Private Endpoint, bypassing the Azure Firewall. (At the Azure Routing Experiences | Scenario 2 we will see how we will force the traffic through the Azure Firewall.

Please find below the whole solution diagram, I tried to make it as analytic as possible, without messing with too many lines. Also, I have some notes and tests below.

References:
Azure Private Endpoint DNS configuration | Microsoft Docs
What is a virtual network link subresource of Azure DNS private zones | Microsoft Docs
Azure Firewall DNS Proxy details | Microsoft Docs
Create, change, or delete an Azure route table | Microsoft Docs

Pantelis Apostolidis

Pantelis Apostolidis is a Sr. Specialist, Azure at Microsoft and a former Microsoft Azure MVP. For the last 20 years, Pantelis has been involved to major cloud projects in Greece and abroad, helping companies to adopt and deploy cloud technologies, driving business value. He is entitled to a lot of Microsoft Expert Certifications, demonstrating his proven experience in delivering high quality solutions. He is an author, blogger and he is acting as a spokesperson for conferences, workshops and webinars. He is also an active member of several communities as a moderator in azureheads.gr and autoexec.gr. Follow him on Twitter @papostolidis.

www.cloudcorner.gr

The post Azure Routing Experiences | Scenario 1 appeared first on Apostolidis Cloud Corner.

Azure Virtual Network Gateway provides the ability to connect to your Azure Virtual Network with Azure Client VPN (SSL) connections using your Azure AD or hybrid identity, with Multi Factor Authentication (MFA) and your Conditional Access policies.

We can have an Enterprise grade SSL VPN, with Active Directory authentication and Single Sign on (SSO) from your corporate laptops and apply all your conditional access policies, like MFA, Compliance devices, trused locations, etc.

How to create the VPN Gateway

Go to your Virtual Network’s subnets and create a Gateway subnet by clicking the “+ Gateway subnet”

Create a Virtual network gateway, by searching for the “Virtual network gateways” service and press Add.

Select “VPN”, “Route-based” and at the SKU select any size except the Basic. Basic SKU does not support Azure AD authentication.

Create a Public IP and leave all other settings default and create the Gateway.

After about 20 minutes the VPN Gateway is ready. In the meantime we will prepare the Azure AD and give concern to use the Azure AD with the Azure client VPN. Using a Global Admin account, go to the “Azure Active Directory” and copy the “Tenant ID” from the Overview blade, and keep it on a notepad.

Then copy the url and paste the below url to your browser’s address bar. You need to log in with a Global Admin non guest non Microsoft account.

https://login.microsoftonline.com/common/oauth2/authorize?client_id=41b23e61-6c1e-4545-b367-cd054e0ed4b4&response_type=code&redirect_uri=https://portal.azure.com&nonce=1234&prompt=admin_consent

With a guest or Microsoft account, even if it is Global Admin, you will be propted to login with an admin account, meaning a member work account.

Once you login with a member work Global Admin account, you can accept the permissions to create the Azure VPN application

You can navigate to the Azure Active Directory / Enterprise Application and view / manage the Azure AD application.

Open the Azure VPN enterprise application and copy the “Application ID” to a notepad.

Go to the VPN Gateway, select the “Point to site configuration” and click the “Configure now”

Add the Address Pool that you want the VPN clients to have, for Tunnel type select “OpenVPN (SSL) as it is the only type that supports Azure AD authentication.

Then use the details that you have copied to the notepad, the Tenant ID and the Application ID, and add them to the required fields and press save.

• Tenant: https://login.microsoftonline.com/paste-your-tenant-id-here
• Audience: paste-the-azure-vpn-application-id-here
• Issuer: https://sts.windows.net/paste-your-tenant-id-here/

How to Download the VPN Client and Connect to the Gateway

Download the VPN client, using the button.

Extrack the downloadded zip file

And at the AzureVPN folder you will find the configuration xml.

Open the Microsoft Store and get the Azure VPN Client

Open the Azure VPN Client and at the lower left corner, press the + and Import the xml configuration file

accept all the settings and press save

The Azure VPN connection will appear at the Azure VPN client and also at the Windows 10 network connections, like any other VPN

Azure VPN Client:

Windows 10 Network Connections:

Once you press connect, it will prompt you to connect using the account(s) that you are already using at your Windows 10 machine, or use a different account

You will be prompted for MFA or any other conditional access policy you have applied, and the you will be connected.

Conditional Access & Multi-Factor Authentication (MFA)

You can add Conditional Access to the Azure client VPN connection. Go to Azure Active Directory / Security / Conditional Access and create a new Policy.

Select the “Azure VPN” at the “Cloud apps or actions” section

At the Access Controls / Grand section, you can require multi-factor authentication, or AD Joined device, or compliant device, or all of that

At the “Conditions” section you can controll the location that the policy will apply. Lets say, you can apply the MFA requirement at “Any location” and exclude the “Trusted locations”, in order to not require MFA when the device is at a trusted location, like your company’s network.

Pantelis Apostolidis

Pantelis Apostolidis is a Sr. Specialist, Azure at Microsoft and a former Microsoft Azure MVP. For the last 20 years, Pantelis has been involved to major cloud projects in Greece and abroad, helping companies to adopt and deploy cloud technologies, driving business value. He is entitled to a lot of Microsoft Expert Certifications, demonstrating his proven experience in delivering high quality solutions. He is an author, blogger and he is acting as a spokesperson for conferences, workshops and webinars. He is also an active member of several communities as a moderator in azureheads.gr and autoexec.gr. Follow him on Twitter @papostolidis.

www.cloudcorner.gr

The post Azure Client VPN with Azure AD auth & MFA | Step by step guide appeared first on Apostolidis Cloud Corner.

Azure Private Link is a new service, currently in Preview, that provides private connectivity from a virtual network or an on-premises network with Site-2-Site VPN to Azure platform as a service (PaaS) Microsoft services. Azure Private Link makes the networking a lot more simple improving the security and eliminating the need for public access.

image from: https://azure.microsoft.com/en-us/services/private-link/

Azure Private Link is a Service mapped to Azure Virtual Networks through a private endpoint. This means that all traffic is routed internally, using private IPs and connectivity, eliminating the exposure to threats. Using Private Link helps an organization to meed the compliance standards.

Azure Private Link is a Global service. It does not have regional restrictions. You can connect privately services from all the Azure Regions around the globe.

Lets Lab It!

Let’s see in practice how we can connect from an Azure VM and from our on-premises computer using VPN to an Azure SQL Database using private IPs. For the Lab I already have a Virtual Machine running Windows Server 2019 and an Azure SQL Database. The SQL Database is not connected to any networks.

Open the Azure Portal, press New and search for “Private Link”, select it and press “Create”

A nice “Getting started page” will open. Click the “Build a private connection to a service”

The “Create a private endpoint” wizard will open. Select a name for the Private Link and a Region and press Next to go to the second step.

At the second step, select to connect to the azure resource in my directory, and select the subscription where the Azure SQL Database resides. Then select the SQL Server.

At the third step, select the VIrtual Network that the Private Link will be created. I selected the network where my Virtual Machine resides. If you don’t have your own DNS server select Yes to create an Azure private DNS zone.

At the final step, review the settings and create the Private Link

After the resource creation, you can check the DNS for the Azure SQL Server Private IP Address!

And at the SQL Server, at the “Private endpoint connections” section you will see the new Private Link.

Open a Remote Desktop Connection to the Azure VM, and run a nslookup for the SQL Server name. In my case the command is:

PS C:\> nslookup plsqlsrv.database.windows.net
Server: UnKnown
Address: 168.63.129.16

Non-authoritative answer:
Name: plsqlsrv.privatelink.database.windows.net
Address: 10.0.2.5
Aliases: plsqlsrv.database.windows.net

And it returned the Private IP address of the SQL Server.

From my computer, i tried to connect to the Azure SQL Server, using the name plsqlsrv.database.windows.net and the connection failed since my Public IP Address is not allowed to access the server.

From the Azure VM I managed to connect successfully and of course internally!

After that, I added a Virtual Network Gateway to the Network and created a Point to Site VPN connection from my local computer to Azure. You can check my guide on how to do this: https://www.e-apostolidis.gr/microsoft/azure/azure-start-point-point-to-site-vpn/

In order to connect to the Azure SQL you need to either use a local DNS server to map the SQl Server name to the Azure SQL IP or add an entry to the local host file for testing.

Conclusion

Azure Private Link is in Preview and currently supports Azure SQL Database and Storage accounts. Additional services coming in preview in next 3-6 months:

• · Cosmos DB
• · App Service Vnet Integration + App Service Environment
• · Azure Kubernetes Service
• · Azure Key Vault
• · PostgreSQL
• · MySQL
• · Maria DB

Source:

https://azure.microsoft.com/en-us/services/private-link/

https://azure.microsoft.com/en-au/blog/announcing-azure-private-link/

Pantelis Apostolidis

Pantelis Apostolidis is a Sr. Specialist, Azure at Microsoft and a former Microsoft Azure MVP. For the last 20 years, Pantelis has been involved to major cloud projects in Greece and abroad, helping companies to adopt and deploy cloud technologies, driving business value. He is entitled to a lot of Microsoft Expert Certifications, demonstrating his proven experience in delivering high quality solutions. He is an author, blogger and he is acting as a spokesperson for conferences, workshops and webinars. He is also an active member of several communities as a moderator in azureheads.gr and autoexec.gr. Follow him on Twitter @papostolidis.

www.cloudcorner.gr

The post Azure Private Link | Private connection to Azure PaaS appeared first on Apostolidis Cloud Corner.

Microsoft Azure ExpressRoute was general available back on 2014. To connect to Azure ExpressRoute you need a direct line with an ExpressRoute provider. Now Microsoft announced that Microsoft cloud services can be accessed with Azure ExpressRoute using satellite connectivity, breaking the direct line barriers, making it feasible to connect your data center directly to Microsoft Azure from all around the globe!

image from https://azure.microsoft.com/en-us/blog/satellite-connectivity-expands-reach-of-azure-expressroute-across-the-globe/

Azure ExpressRoute Satellite connectivity is currently provided by three Microsoft partners, Intelsat, SES, and Viasat. Microsoft expands its already large connectivity, adding Satellite connectivity options at the  54 Regions worldwide making Microsoft’s global network one of the largest in the world.

Source:

https://docs.microsoft.com/en-us/azure/expressroute/expressroute-introduction

https://azure.microsoft.com/en-us/blog/satellite-connectivity-expands-reach-of-azure-expressroute-across-the-globe/

Pantelis Apostolidis

Pantelis Apostolidis is a Sr. Specialist, Azure at Microsoft and a former Microsoft Azure MVP. For the last 20 years, Pantelis has been involved to major cloud projects in Greece and abroad, helping companies to adopt and deploy cloud technologies, driving business value. He is entitled to a lot of Microsoft Expert Certifications, demonstrating his proven experience in delivering high quality solutions. He is an author, blogger and he is acting as a spokesperson for conferences, workshops and webinars. He is also an active member of several communities as a moderator in azureheads.gr and autoexec.gr. Follow him on Twitter @papostolidis.

www.cloudcorner.gr

The post Azure ExpressRoute adds Satellite connectivity appeared first on Apostolidis Cloud Corner.

At this post we will see how to make a high available connection between our on-premises network and Azure. This way we will have an Active-Active Dual-Redundancy VPN Connection.

The idea behind this is that we have a router/firewall cluster,connected with two ISPs and we want to also have a VPN connection with Azure using both ISPs actively. I call this an end-to-end high available connectivity between our on-premises infrastructure and Azure. Actually the active-active dual redundant connections needs to have two different on-premises VPN devices, but we can accomplish almost the same functionality with one device and two different interfaces with two different ISPs.

The requirement for this topology, except the router/firewall cluster and the two ISPs is that the Azure VPN Gateway must be Standard or HighPerformance SKU. The Basic SKU does not support Active-Active mode.

As you can see at the above diagram, the Active-Active VPN Gateway created two Active VPN Nodes. The connection of each node to each on-premises network interface in a mesh topology. All network traffic is distributed through all the connections. In order to accomplish this connectivity we need to also enable BGP to both on-premises device and Azure VPN Gateway with different ASN.

Lets lab it:

Create a Virtual Network Gateway, VPN, Route Based and SKU VpnGw1 or larger

Enable active-active mode, this will create two nodes, and give the names of the two Public IPs.

Check the Configure BGB ASN and change the default ASN, I used 65510

wait a lot… more than the typical 45 minutes, a lot more…

When the gateway is created you will see that the public ip address is called “First public IP address”. If you click the “see more” link you will see the second IP too.

You can see both IP form the Properties page too.

Second we need to create two Local network Gateways, to represent the two interfaces of our on-premises device. Both must be created with the same ASN. This ASM must be different than the Gateways’ and this ASN must be configured at the configuration of the local devices VPN connection.

]

Now, create the connection

And remember to enable BGP at the Connection’s Configuration

As soon as the local device is configured both connections became connected.

From powershell we can see both local IPs of the two nodes of the Azure VPN Gateway,

Test and Troubleshooting

Currently the only way to see the connections between the Azure Gateway Nodes and the local devices interfaces is the below powershell command

Get-AzureRmVirtualNetworkGatewayBGpPeerStatus -VirtualNetworkGatewayName “gatewayname” -ResourceGroup “resourcegroupname”

Every time you run this command you get answer from one of the two nodes at random. At the above screenshot, first is one node and second is the other.

The first node’s peer, 192.168.xx.9 shows that is connected to the 10.xx.xx.2 local network’s peer and connecting at the second peer 10.xx.xx.1

The second node’s peer, 192.168.xx.8 shows that is connected to the 10.xx.xx.1 local network’s peer and connecting at the second peer 10.xx.xx.2

The test I performed was to unplug one interface from the local device. The azure gateway’s first node State was both Connecting and the second node was the same, connecting to .2 and connected to .1.  At this test I did lost a single ping.

After that I plugged the cable back, waited less than a minute and unplugged the second cable. Now the first node shows still disconnected but the first node connected to the .2 local IP and connecting to .1. With this test I lost only one ping. Also I realized that it is random which node’s private IP will connect with the local device’s private IP. Both Azure Gateway’s IPs 192.168.x.8 & 9 can connect with the local device’s IP 10.x.x.1 & 2 and this is the magic of the Active-Active Dual Redundancy VPN connection.

Pantelis Apostolidis

Pantelis Apostolidis is a Sr. Specialist, Azure at Microsoft and a former Microsoft Azure MVP. For the last 20 years, Pantelis has been involved to major cloud projects in Greece and abroad, helping companies to adopt and deploy cloud technologies, driving business value. He is entitled to a lot of Microsoft Expert Certifications, demonstrating his proven experience in delivering high quality solutions. He is an author, blogger and he is acting as a spokesperson for conferences, workshops and webinars. He is also an active member of several communities as a moderator in azureheads.gr and autoexec.gr. Follow him on Twitter @papostolidis.

www.cloudcorner.gr

The post Create an Ultra High Available on-prem <-> Azure VPN Connection appeared first on Apostolidis Cloud Corner.

Peering is a feature that allows to connect two or more virtual networks and act as one bigger network. At this post we will see how we can connect two Azure Virtual Networks, using peering and access the whole network using one VPN Gateway. We can connect Virtual Networks despite if they are in the same Subscription or not.

I have created a diagram to help understand the topology.

• We have a Virtual Network with Site-2-Site VPN wto On Premises. It can also have Point-2-Site connection configured. The VNET A.
• We have another Virtual Network at the Same Subscription that we want to connect each other. The VNET B.
• Also we can have a third Virtual Network at a different subscription. The VNET C.

In sort we need those peerings with the specific settings:

• At the VNETA Peering VNETA to VNETB with “Allow Gateway transit”
• At the VNETA Peering VNETA to VNET
• At the VNETB Peering VNETB to VNETA with “Use Remote Gateway”
• At the VNETB Peering VNETB to VNETC
• At the VNETC Peering VNETC to VNETA with “Use Remote Gateway”
• At the VNETC Peering VNETC to VNETB

In order to be able to connect all those networks and also access them using the VPN Connection there are four requirements:

• The account that will be used to create the peering must have the “Network Contributor” Role.
• The Address Space must be different on each other and not overlap.
• All other Virtual Networks, except the one that has the VPN Connection must NOT have a VPN Gateway deployed.
• Of course at the local VPN device (router) we need to add the address spaces of all the Virtual Networks that we need to access.

Lets lab it:

• HQ 192.168.0.0/16 –> The on-premises network
• VNET A 10.1.0.0/16 –> The Virtual Network that has the VPN Gateway (At my lab is named “devvn”)
• VNET B 10.229.128.0/24 –> THe virtual network at a different subscription of the Gateway (At my lab is named “Network prtg-rsg-vnet”)
• VNET C 172.16.1.0/24 –> The virtual network at the same subscription as the Gateway Network (At my lab is named “provsevnet)

The on-premises network is connected with Site-to-site (IPsec) VPN to the VNETA

Now we need to connect VNETA and VNETB using Vnet Peering. in order to have a Peering connection we need to create a connection from VNETA to VNETB and one from VNETB to VNETA.

Open the VNETA Virtual Network, go to the Peerings setting and press +ADD

Select the VNETB and check the “Allow Gateway transit” to allow the peer virtual network to use your virtual network gateway

Then go to the VNETB, go to the Peerings setting and click +ADD.

Select the VNETA Virtual Network and check the “Use Remote Gateway”  to use the peer’s virtual network gateway. This way the VNETB will use the VNETA’s Gateway.

Now we can contact the VNETB network from our on-premises network

a multi-ping screenshot:

• From 10.229.128.5 (VNETB) to 192.168.0.4 (on-premises) & the opposite
• From 10..1.2.4 (VNETA) to 10.229.128.5 (VNETB)  & to 192.168.0.4 (on-premises)

The next step is to create a cross-subscription peering VNETA with VNETC

Open the VNETA and create a peering by selecting the VNETC from the other Subscription and check the “allow gateway transit”

Then go to the VNETC and create a peer with the VNETA and check the “use remote gaeway”

With the two above connections we have connectivity between the on-premises network and the VNETC.

The final step, to enable the connectivity between VNETB & VNETC. To accomplish this just create one peer from the VNETB to VNETC and one from VNETC to VNETB.

Ping inception:

In order to have client VPN connectivity to the whole network, create a Point-2-Site VPN at the VNETA. You can follow this guide: Azure Start Point | Point-to-Site VPN

Pantelis Apostolidis

Pantelis Apostolidis is a Sr. Specialist, Azure at Microsoft and a former Microsoft Azure MVP. For the last 20 years, Pantelis has been involved to major cloud projects in Greece and abroad, helping companies to adopt and deploy cloud technologies, driving business value. He is entitled to a lot of Microsoft Expert Certifications, demonstrating his proven experience in delivering high quality solutions. He is an author, blogger and he is acting as a spokesperson for conferences, workshops and webinars. He is also an active member of several communities as a moderator in azureheads.gr and autoexec.gr. Follow him on Twitter @papostolidis.

www.cloudcorner.gr

The post Connect two or more Azure Virtual Networks using one VPN Gateway appeared first on Apostolidis Cloud Corner.

In this post series we will go through some basic steps on how to start with Microsoft Azure. At this post we will see how we can create Point-to-Site VPN connection with Azure.

If you don’t have an Azure Subscription, you can easily create a free trial by just going to https://azure.microsoft.com/en-us/free/

Create typical a VIrtual Network

In order to create Point-to-Site VPN connection it needs a Virtual Network Gateway. Go to the Virtual Network, Subnets and add a Gateway Subnet.

FInally we can add the Virtual Network Gateway. From the portal, create a Virtual Network Gateway resource and add it to the previously created Virtual Network.

The Virtual Network Gateway can take up to 45 minutes to be created.

Once the Virtual Network Gateway is created we need one more step. To configure Point-to-site. Open the Virtual Network Gateway and press configure.

We will need a root and a client self-signed certificate to complete the setup. Using a WIndows 10 or Windows Server 2016 machine we can make use of the New-SelfSignedCertificate cmdlet that makes the process easy. The whole process is described here: https://docs.microsoft.com/en-us/azure/vpn-gateway/vpn-gateway-certificates-point-to-site

For the root certificate run the below PowerShell using ISE:

$cert = New-SelfSignedCertificate -Type Custom -KeySpec Signature `
-Subject "CN=prodevrootcert" -KeyExportPolicy Exportable `
-HashAlgorithm sha256 -KeyLength 2048 `
-CertStoreLocation "Cert:\CurrentUser\My" -KeyUsageProperty Sign -KeyUsage CertSign

For the client certificate run the below PowerShell using ISE:

New-SelfSignedCertificate -Type Custom -DnsName ProDevChildCert -KeySpec Signature `
-Subject "CN=ProDevChildCert" -KeyExportPolicy Exportable `
-HashAlgorithm sha256 -KeyLength 2048 `
-CertStoreLocation "Cert:\CurrentUser\My" `
-Signer $cert -TextExtension @("2.5.29.37={text}1.3.6.1.5.5.7.3.2")

Export the root certificate in cer format using MMC, open the Certificates snap-in and select “current user”. Find the root certificate under Personal –> Certificates and right click –> All Tasks export

Select to “not export the private key” and use Base64 encoded.

Now you have the prodevrootcert.cer

After that, export the client certificate by selecting “export the private key” , select the “include all certificates in the certification path” and the “enable certificate privacy”. Add a password and export it to pfx file.

Now you have the prodevchildcert.pfx. This pfx file must be installed to all the client computers that will use this Point-to-Site connection.

Now lets go back to the Point-to-Site configuration page. Add an address pool that the VPN clients will use. This subnet must be different from the Virtual Network address space.

Then open the root certificate, the cer file, using notepad, copy the text between the Begin and End marks.

Paste the certificate text to the “Root certificated” –> Public certificate data” field and add a name to the “Name” field.

Press Save and the “Download VPN Client” button will be enabled and we can download the VPN client.

In order to establish the VPN connection we need to install the VPN Client and the Client “pfx” certificate to the workstation.

Pantelis Apostolidis

Pantelis Apostolidis is a Sr. Specialist, Azure at Microsoft and a former Microsoft Azure MVP. For the last 20 years, Pantelis has been involved to major cloud projects in Greece and abroad, helping companies to adopt and deploy cloud technologies, driving business value. He is entitled to a lot of Microsoft Expert Certifications, demonstrating his proven experience in delivering high quality solutions. He is an author, blogger and he is acting as a spokesperson for conferences, workshops and webinars. He is also an active member of several communities as a moderator in azureheads.gr and autoexec.gr. Follow him on Twitter @papostolidis.

www.cloudcorner.gr

The post Azure Start Point | Point-to-Site VPN appeared first on Apostolidis Cloud Corner.

This post is part of a general idea, to create an end-to-end high available application infrastructure solution in Azure using internal load balancer with the new AzureRm commands and Azure PowerShell v.1.0 preview.

We will create a Gateway, request a Public IP and establish a Site to Site VPN. At the time I am writting this post there is no option to create the VPN ising the Portal, the only way is using PowerShell. Also there is no option to download the configuration  for the local firewall/router, like the classic deployment.

The AzureRm commands are installed directly from the PowerShell using the Install-Module AzureRM & Install-AzureRM commands.

So lets start:

#Login
Login-AzureRmAccount

#Create Gateway for VPN

# add the local (office) public ip and local networks
$resourcegroupName ="RMDemoRG"
$locationName ="West Europe"
$vnetName = "NRPVnet"
New-AzureRmLocalNetworkGateway -Name localsite -ResourceGroupName $resourcegroupName -Location $locationName -GatewayIpAddress "XXX.XXX.XXX.XXX" -AddressPrefix @('10.0.0.0/24','192.168.0.0/24')

# Create the Gateway Subnet
$vnet = Get-AzureRmVirtualNetwork -ResourceGroupName $resourcegroupName -Name $vnetName 
Add-AzureRmVirtualNetworkSubnetConfig -Name 'GatewaySubnet' -AddressPrefix 172.16.0.0/16 -VirtualNetwork $vnet
Set-AzureRmVirtualNetwork -VirtualNetwork $vnet

# create gateway and request azure public ip
$gwpip= New-AzureRmPublicIpAddress -Name RMDemoPIP -ResourceGroupName $resourcegroupName -Location $locationName -AllocationMethod Dynamic
$vnet = Get-AzureRmVirtualNetwork -Name $vnetName -ResourceGroupName $resourcegroupName
$GWsubnet = Get-AzureRmVirtualNetworkSubnetConfig -Name 'GatewaySubnet' -VirtualNetwork $vnet
$gwipconfig = New-AzureRmVirtualNetworkGatewayIpConfig -Name gwipconfig1 -SubnetId $GWsubnet.Id -PublicIpAddressId $gwpip.Id
New-AzureRmVirtualNetworkGateway `
            -Name RMDemoGW `
            -ResourceGroupName $resourcegroupName `
            -Location $locationName `
            -IpConfigurations $gwipconfig `
            -GatewayType Vpn `
            -VpnType PolicyBased #PolicyBased For Static & RouteBased for Dynamic VPN

# Get the Public IP
Get-AzureRmPublicIpAddress -Name RMDemoPIP -ResourceGroupName $resourcegroupName

# Establish the VPN connection
$gateway1 = Get-AzureRmVirtualNetworkGateway -Name RMDemoGW -ResourceGroupName $resourcegroupName
$local = Get-AzureRmLocalNetworkGateway -Name LocalSite -ResourceGroupName $resourcegroupName
New-AzureRmVirtualNetworkGatewayConnection `
            -Name localtovpn `
            -ResourceGroupName $resourcegroupName `
            -Location $locationName `
            -VirtualNetworkGateway1 $gateway1 `
            -LocalNetworkGateway2 $local `
            -ConnectionType IPsec `
            -RoutingWeight 10 `
            -SharedKey 'ABCDEFG1234567890'

#check the VPN status
Get-AzureRMVirtualNetworkGatewayConnection -Name localtovpn -ResourceGroupName $resourcegroupName -Debug

Finally, since there is no way to download the configuration script at this time, the sample configurations can be found here: https://github.com/Azure/Azure-vpn-config-samples

After the creation of the VPN, that can be done only using PowerShell, we can use the portal to view the status and the settings

Pantelis Apostolidis

Pantelis Apostolidis is a Sr. Specialist, Azure at Microsoft and a former Microsoft Azure MVP. For the last 20 years, Pantelis has been involved to major cloud projects in Greece and abroad, helping companies to adopt and deploy cloud technologies, driving business value. He is entitled to a lot of Microsoft Expert Certifications, demonstrating his proven experience in delivering high quality solutions. He is an author, blogger and he is acting as a spokesperson for conferences, workshops and webinars. He is also an active member of several communities as a moderator in azureheads.gr and autoexec.gr. Follow him on Twitter @papostolidis.

www.cloudcorner.gr

The post AzureRm | Create Site to Site VPN appeared first on Apostolidis Cloud Corner.