• 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

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.

This is a template that first creates a Resource Group, and then it deploys a Virtual Machine from an image version of the Shared Image Gallery. It provides the Public IP and Hostname for outputs. 

Currently it only asks for the SIG image version and an environment value to create the naming convention of the resources. 

GitHub: https://github.com/proximagr/ARMTemplates/blob/master/VM-from-SIG-in-new-RG/VM-from-SIG-in-new-RG.json

{
    "$schema": "https://schema.management.azure.com/schemas/2018-05-01/subscriptionDeploymentTemplate.json#",
    "contentVersion": "1.0.0.0",
    "parameters": {
        "galleryimageversion": {
            "type": "string",
            "defaultValue": "10.0.2"
        },
        "envname": {
            "type": "string",
            "defaultValue": "test"
        }
    },
    "variables": {
        "basename": "[concat(parameters('envname'),substring(deployment().name,0,6))]",
        "rgname": "[concat('rg-', substring(variables('basename'), 0, 10))]",
        "region": "francecentral"
    },
    "resources": [
        {
            "name": "[variables('rgname')]",
            "type": "Microsoft.Resources/resourceGroups",
            "apiVersion": "2019-10-01",
            "location": "[variables('region')]",
            "dependsOn": [
            ],
            "tags": {
            }
        },
        {
            "type": "Microsoft.Resources/deployments",
            "resourceGroup": "[variables('rgname')]",
            "dependsOn": [
                "[resourceId('Microsoft.Resources/resourceGroups',variables('rgname'))]"
            ],
            "apiVersion": "2019-10-01",
            "name": "nestedTemplate1",
            "properties": {
                "expressionEvaluationOptions": {
                    "scope": "inner"
                },
                "mode": "Incremental",
                "parameters": {
                    "galleryImageVersionName": {
                        "value": "[parameters('galleryimageversion')]"
                    },
                    "envname": {
                        "value": "[parameters('envname')]"
                    }

                },
                "template": {
                    "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
                    "contentVersion": "1.0.0.0",
                    "parameters": {
                        "galleryImageVersionName": {
                            "type": "string"
                        },
                        "envname": {
                            "type": "string"
                        }
                    },
                    "variables": {
                        "basename": "[concat(parameters('envname'),substring(deployment().name,0,6))]",
                        "pubipname": "[concat( 'pip-',variables('basename'))]",
                        "pubipdns": "[concat( 'vm-',variables('basename'))]",
                        "region": "francecentral",
                        "adminUsername": "uiadmin",
                        "adminPassword": "ThisIs1Password!",
                        "galleryName": "demosig",
                        "galleryImageDefinitionName": "demoid",
                        "nicName": "[concat( 'nic-',variables('basename'))]",
                        "addressPrefix": "10.0.0.0/24",
                        "subnetName": "[concat( 'sub-',variables('basename'))]",
                        "subnetPrefix": "10.0.0.0/24",
                        "vmName": "[concat( 'vm-',variables('basename'))]",
                        "virtualNetworkName": "[concat( 'vnet-',variables('basename'))]",
                        "subnetRef": "[resourceId('Microsoft.Network/virtualNetworks/subnets', variables('virtualNetworkName'), variables('subnetName'))]",
                        "networkSecurityGroupName": "[concat( 'nsg-',variables('basename'))]"
                    },
                    "resources": [
                        {
                            "name": "[variables('pubipname')]",
                            "type": "Microsoft.Network/publicIPAddresses",
                            "apiVersion": "2019-11-01",
                            "location": "[variables('region')]",
                            "tags": {
                                "displayName": "publicIPAddress1"
                            },
                            "properties": {
                                "publicIPAllocationMethod": "Static",
                                "dnsSettings": {
                                    "domainNameLabel": "[variables('pubipdns')]"
                                }
                            }
                        },
                        {
                            "comments": "Simple Network Security Group for subnet [variables('subnetName')]",
                            "type": "Microsoft.Network/networkSecurityGroups",
                            "apiVersion": "2019-08-01",
                            "name": "[variables('networkSecurityGroupName')]",
                            "location": "[variables('region')]",
                            "properties": {
                                "securityRules": [
                                    {
                                        "name": "default-allow-22",
                                        "properties": {
                                            "priority": 1000,
                                            "access": "Allow",
                                            "direction": "Inbound",
                                            "destinationPortRange": "22",
                                            "protocol": "Tcp",
                                            "sourceAddressPrefix": "*",
                                            "sourcePortRange": "*",
                                            "destinationAddressPrefix": "*"
                                        }
                                    },
                                    {
                                        "name": "default-allow-3389",
                                        "properties": {
                                            "priority": 1001,
                                            "access": "Allow",
                                            "direction": "Inbound",
                                            "destinationPortRange": "3389",
                                            "protocol": "Tcp",
                                            "sourceAddressPrefix": "*",
                                            "sourcePortRange": "*",
                                            "destinationAddressPrefix": "*"
                                        }
                                    }
                                ]
                            }
                        },
                        {
                            "type": "Microsoft.Network/virtualNetworks",
                            "name": "[variables('virtualNetworkName')]",
                            "apiVersion": "2016-03-30",
                            "location": "[variables('region')]",
                            "dependsOn": [
                                "[resourceId('Microsoft.Network/networkSecurityGroups', variables('networkSecurityGroupName'))]"
                            ],
                            "properties": {
                                "addressSpace": {
                                    "addressPrefixes": [
                                        "[variables('addressPrefix')]"
                                    ]
                                },
                                "subnets": [
                                    {
                                        "name": "[variables('subnetName')]",
                                        "properties": {
                                            "addressPrefix": "[variables('subnetPrefix')]",
                                            "networkSecurityGroup": {
                                                "id": "[resourceId('Microsoft.Network/networkSecurityGroups', variables('networkSecurityGroupName'))]"
                                            }
                                        }
                                    }
                                ]
                            }
                        },
                        {
                            "type": "Microsoft.Network/networkInterfaces",
                            "name": "[variables('nicName')]",
                            "apiVersion": "2016-03-30",
                            "location": "[variables('region')]",
                            "properties": {
                                "ipConfigurations": [
                                    {
                                        "name": "ipconfig1",
                                        "properties": {
                                            "privateIPAllocationMethod": "Dynamic",
                                            "publicIPAddress": {
                                                "id": "[resourceId('Microsoft.Network/publicIPAddresses',variables('pubipname'))]"
                                            },
                                            "subnet": {
                                                "id": "[variables('subnetRef')]"
                                            }
                                        }
                                    }
                                ]
                            },
                            "dependsOn": [
                                "[resourceId('Microsoft.Network/publicIPAddresses/', variables('pubipname'))]",
                                "[resourceId('Microsoft.Network/virtualNetworks/', variables('virtualNetworkName'))]"
                            ]
                        },
                        {
                            "type": "Microsoft.Compute/virtualMachines",
                            "name": "[variables('vmName')]",
                            "apiVersion": "2019-07-01",
                            "location": "[variables('region')]",
                            "properties": {
                                "hardwareProfile": {
                                    "vmSize": "Standard_F8s_v2"
                                },
                                "osProfile": {
                                    "computerName": "[variables('vmName')]",
                                    "adminUsername": "[variables('adminUsername')]",
                                    "adminPassword": "[variables('adminPassword')]"
                                },
                                "storageProfile": {
                                    "imageReference": {
                                        "id": "[resourceId('Microsoft.Compute/galleries/images/versions', variables('galleryName'), variables('galleryImageDefinitionName'), parameters('galleryImageVersionName'))]"
                                    }
                                },
                                "networkProfile": {
                                    "networkInterfaces": [
                                        {
                                            "id": "[resourceId('Microsoft.Network/networkInterfaces',variables('nicName'))]"
                                        }
                                    ]
                                }
                            },
                            "dependsOn": [
                                "[resourceId('Microsoft.Network/networkInterfaces/', variables('nicName'))]"
                            ]
                        }
                    ],
                    "outputs": {
                        "publicipn": {
                            "type": "string",
                            "value": "[reference(variables('pubipname')).dnsSettings.fqdn]"
                        },
                        "publicipa": {
                            "type": "string",
                            "value": "[reference(variables('pubipname')).ipAddress]"
                        }
                    }
                }
            }
        }
    ],
    "outputs": {
        "hostname": {
            "type": "string",
            "value": "[reference('nestedTemplate1').outputs.publicipn.value]"
        },
        "ipaddress": {
            "type": "string",
            "value": "[reference('nestedTemplate1').outputs.publicipa.value]"
        }
    }
}

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 Deploy VM from Azure SIG in new Resource Group appeared first on Apostolidis Cloud Corner.

Infrastructure as Code, or just IaC, provides three three main advantages: cost reduction, faster execution and risk reduction, the attributes of the DevOps culture.

Microsoft Azure Resource Manager allows the managing and provisioning of Azure Resources, that can be Virtual Machines, Virtual Networks, Storage Accounts, Apps, SQL Databases and everything that a computer data center includes, through machine-readable definition files, known as JSON templates, without the need of physical hardware configuration or interactive configuration tools.

I am starting a series of posts about building infrastructure with JSON templates.

The tool I use to build my Azure Json templates is the Visual Studio Code. You can download it from https://code.visualstudio.com/ for every platform.

To work with Azure Resource Manager you need the Azure Resource Manager Tools extension. Open the VS Code, go to the Extensions Section, search and install the Azure Resource Manager Tools extension.

The extension is very helpful since it highlights the code, it provides references and intellisense.

At this post I am sharing & explaining my Azure json template for deploying a Virtual Network, a Network Security Group and a Route Table.

You can find and download my working template at my Git account :

https://github.com/proximagr/ARMTemplates/tree/master/VNET-2sub-NSG-UDR

Json Template Guide

Below you can find my template with comments, for better understanding.

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "parameters": {
//** Define the Virtual Network Name */
    "vnetName": {
      "type": "string",
      "defaultValue": "Cloud-Corner-VNET",
      "metadata": {
        "description": "Cloud Corner VNET"
      }
//** Define the Address Space of the Virtual Network */
    },
      "vnetAddressPrefix": {
        "type": "string",
        "defaultValue": "10.0.0.0/24",
        "metadata": {
          "description": "Address prefix"
        }
//** Define the Address Space of the the First Subnet */
      },
      "subnet1Prefix": {
        "type": "string",
        "defaultValue": "10.0.0.0/27",
        "metadata": {
          "description": "Subnet 1 Prefix"
        }
//** Define the Name of the the First Subnet */
      },
      "subnet1Name": {
        "type": "string",
        "defaultValue": "Subnet1",
        "metadata": {
          "description": "Subnet 1 Name"
        }
//** Define the Address Space of the the Second Subnet */
      },
      "subnet2Prefix": {
        "type": "string",
        "defaultValue": "10.0.0.32/27",
        "metadata": {
          "description": "Subnet 2 Prefix"
        }
//** Define the Name of the the First Subnet */
      },
      "subnet2Name": {
        "type": "string",
        "defaultValue": "Subnet2",
        "metadata": {
          "description": "Subnet 2 Name"
        }
      },
//** Define the Name of the the Network Security Group */
      "networkSecurityGroup01Name": {
        "type": "string",
        "defaultValue": "Cloud-Corner-NSG-01",
        "metadata": {
          "description": "This is the name of the network security group"
        }
      },
//** Define the Name of the the First Route Table */
      "RouteTable01Name": {
        "type": "string",
        "defaultValue": "Cloud-Corner-UDR-01",
        "metadata": {
        "description": "Route Table 01 Name."
        }
      },
//** Define the Name of the the First Route of the First Route Table */
      "Route01Name": {
        "type": "string",
        "defaultValue": "To-internet",
        "metadata": {
          "description": "Route 01 Name."
        }
      },
//** Define the Next Hop Type of the the First Route of the First Route Table */
      "Route01NextHopType": {
        "type": "string",
        "allowedValues": [
        "VirtualNetworkGateway",
        "VnetLocal",
        "Internet",
        "VirtualAppliance",
        "None"
      ],
      "defaultValue": "VirtualAppliance",
        "metadata": {
          "description": "Route 01 Next Hop Type."
        }
      },
//** Define the Address Prefix of the First Route of the First Route Table */
      "Route01AddressPrefix": {
        "type": "string",
        "defaultValue": "0.0.0.0/0",
        "metadata": {
          "description": "Route 01 Address Prefix."
        }
      },
//** If you set "Virtyal Appliance for Next Hop Type, then you need to define the Next Hop IP Address, */
//** meaning the appliance's IP address. Here you define it for the First Route of the First Route Table */
        "RT01Route01NextHopIPAddress": {
        "type": "string",
        "defaultValue": "10.0.0.40",
        "metadata": {
          "description": "Next Hop IP Addess."
        }
      },
//** Define the Name of the Second Route Table */
      "RouteTable02Name": {
        "type": "string",
        "defaultValue": "Cloud-Corner-UDR-02",
        "metadata": {
          "description": "Route Table 02 Name."
        }
      },
//** Define the Name of the the First Route of the Second Route Table */
      "RT02Route01Name": {
        "type": "string",
        "defaultValue": "Local-Subnet",
        "metadata": {
        "description": "Route Table 02 Route 01 Name."
        }
      },
//** Define the Next Hop Type of the the First Route of the Second Route Table */
      "RT02Route01NextHopType": {
        "type": "string",
        "allowedValues": [
        "VirtualNetworkGateway",
        "VnetLocal",
        "Internet",
        "VirtualAppliance",
        "None"
      ],
      "defaultValue": "VnetLocal",
        "metadata": {
          "description": "Route 02 Next Hop Type."
        }
      },
//** Define the Address Prefix of the the First Route of the Second Route Table */
      "RT02Route01AddressPrefix": {
        "type": "string",
        "defaultValue": "10.0.0.0/27",
        "metadata": {
          "description": "Route Table 02 Route 01 Address Prefix."
        }
      },
//** Define the Name of the the Second Route of the Second Route Table */
        "RT02Route02Name": {
          "type": "string",
          "defaultValue": "To-subnet-1",
          "metadata": {
            "description": "Route Table 02 Route 01 Name."
          }
        },
//** Define the Next Hop Type of the the Second Route of the Second Route Table */
        "RT02Route02NextHopType": {
          "type": "string",
          "allowedValues": [
          "VirtualNetworkGateway",
          "VnetLocal",
          "Internet",
          "VirtualAppliance",
          "None"
        ],
        "defaultValue": "VirtualAppliance",
          "metadata": {
            "description": "Route 02 Next Hop Type."
          }
        },
//** Define the address prefix of the the Second Route of the Second Route Table */
        "RT02Route02AddressPrefix": {
          "type": "string",
          "defaultValue": "10.0.0.32/27",
          "metadata": {
            "description": "Route Table 02 Route 01 Address Prefix."
          }
      },
//** Define the next hop IP address (the virtual appliance's address) of the the Second Route of the Second Route Table */
        "RT02Route02NextHopIPAddress": {
          "type": "string",
          "defaultValue": "10.0.0.40",
          "metadata": {
            "description": "Next Hop IP Addess."
          }
        }
    },
//** I dont use any variables, you can exclude this section*/
  "variables": {},
  "resources": [
//* create the First Route Table & Route*/
    {
    "apiVersion": "2017-10-01",
    "type": "Microsoft.Network/routeTables",
    "name": "[parameters('RouteTable01Name')]",
    "location": "[resourceGroup().location]",
    "properties": {
    "disableBgpRoutePropagation": true,
    "routes": [
      {
        "name": "[parameters('Route01Name')]",
        "properties": {
          "addressPrefix": "[parameters('Route01AddressPrefix')]",
          "nextHopType": "[parameters('Route01NextHopType')]",
          "nextHopIpAddress": "[parameters('RT01Route01NextHopIPAddress')]"
          }
        }
      ]
    }
  },
//* create the Second Route Table & Routes*/
    {
    "apiVersion": "2017-10-01",
    "type": "Microsoft.Network/routeTables",
    "name": "[parameters('RouteTable02Name')]",
    "location": "[resourceGroup().location]",
    "properties": {
    "disableBgpRoutePropagation": true,
    "routes": [
      {
        "name": "[parameters('RT02Route01Name')]",
        "properties": {
          "addressPrefix": "[parameters('RT02Route01AddressPrefix')]",
          "nextHopType": "[parameters('RT02Route01NextHopType')]"
        }
      },
          {
        "name": "[parameters('RT02Route02Name')]",
        "properties": {
          "addressPrefix": "[parameters('RT02Route02AddressPrefix')]",
          "nextHopType": "[parameters('RT02Route02NextHopType')]",
          "nextHopIpAddress": "[parameters('RT02Route02NextHopIPAddress')]"
          }
        }
      ]
    }
  },
//* create teh Network Security Group */
    {
    "apiVersion": "2019-02-01",
    "type": "Microsoft.Network/networkSecurityGroups",
    "name": "[parameters('networkSecurityGroup01Name')]",
    "location": "[resourceGroup().location]",
    "properties": {
      "securityRules": [
        {
          "name": "HTTPS",
          "properties": {
            "description": "Open HTTPS to Public",
            "protocol": "Tcp",
            "sourcePortRange": "443",
            "destinationPortRange": "443",
            "sourceAddressPrefix": "*",
            "destinationAddressPrefix": "*",
            "access": "Allow",
            "priority": 101,
            "direction": "Inbound"
            }
          }
        ]
      }
    },
//* create the Virtual Network */
    {
      "apiVersion": "2018-10-01",
      "type": "Microsoft.Network/virtualNetworks",
      "name": "[parameters('vnetName')]",
      "location": "[resourceGroup().location]",
//*add a dependency in order to ensure that the NSG is created before the VNET, in order to be able to attach it*/
      "dependsOn": [
        "[parameters('networkSecurityGroup01Name')]"
      ],
      "properties": {
        "AddressSpace": {
          "AddressPrefixes": [
            "[parameters('vnetAddressPrefix')]"
          ]
        }
      },
      "resources": [
//* create the first subnet */
        {
        "apiVersion": "2018-10-01",
        "type": "subnets",
        "location": "[resourceGroup().location]",
        "name": "[parameters('subnet1Name')]",
//* add dependencies to create the resources with an order, because you need to ensure that the VNET is ready before creating the Subnet and also the Route Table*/
        "dependsOn": [
          "[parameters('vnetName')]",
          "[resourceId('Microsoft.Network/routeTables', parameters('RouteTable01Name'))]"
        ],
        "properties": {
        "AddressPrefix": "[parameters('subnet1Prefix')]",
//*attach the Newtork Securoty Group to the Subnet*/
        "networkSecurityGroup": {
        "id": "[resourceId('Microsoft.Network/networkSecurityGroups', parameters('networkSecurityGroup01Name'))]"},
//*attacht the First route table to the Subnet*/
        "routeTable": {
        "id": "[resourceId('Microsoft.Network/routeTables', parameters('RouteTable01Name'))]"
          }
         }
        },
//*create the second subnet*/
        {
        "apiVersion": "2018-10-01",
        "type": "subnets",
        "location": "[resourceGroup().location]",
        "name": "[parameters('subnet2Name')]",
        "dependsOn": [
          "[parameters('vnetName')]",
          "[parameters('subnet1Name')]",
          "[parameters('RouteTable02Name')]"
        ],
        "properties": {
          "AddressPrefix": "[parameters('subnet2Prefix')]",
//*attach the Newtork Securoty Group to the Subnet*/
          "networkSecurityGroup": {
          "id": "[resourceId('Microsoft.Network/networkSecurityGroups', parameters('networkSecurityGroup01Name'))]"},
//*attacht the second route table to the Subnet*/
          "routeTable": {
          "id": "[resourceId('Microsoft.Network/routeTables', parameters('RouteTable02Name'))]"
            }
          }
        }
      ]
    }
  ]
}

Deploy the template

Deploy the template directly from here:

More Azure Resource Manager Templates: https://www.e-apostolidis.gr/microsoft/azure/create-azure-file-shares-using-arm-template-powershell/

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 Infrastructure as Code | Deploy a VNET & NSG & UDR appeared first on Apostolidis Cloud Corner.

Azure Policy is a powerful tool for Azure Governance. With Azure Policy we can define rules for all Azure Subscriptions the we manage. We can use this rules for simple limitation actions, like permitting only specific VM Series and Sizes that can be created and also more complex rule sets that helps you standardize the whole Azure deployment. At my previous posts, we learned How to limit the Azure VM Sizes and How to enforce tags for resources creation

At the current post we will learn how to use Azure Policy to have a compliance report for our deployment. We will learn this by using an example. Then we will create two Virtual Networks and we will add a Network Security Group only to the first one. Finally we will use the Policy to audit whether the Subnets have assigned the NSG or Not.

First we need two Virtual Networks. You can create the Virtual Networks using the Azure Portal or using ARM template, like mine from my Github account: https://github.com/proximagr/ARMTemplates/blob/master/2vnets.json

After applying the template you will have two VNETs like that:

Then we will a Network Security Group (NSG) only to the MyVNET01 Virtual Network. Again using Azure Portal, PowerShell or my ARM Template for NSG

Assign the NSG to the MyVNET01 VIrtual Network

Add the Policy

Go to Azure Policy -> Definitions and click the “+ Policy definition” to create a new policy definition.

At the New Policy definition page, select the subscription (location) that the policy will be saved, then add a name. in this case we will use the sample policy template from Microsoft docs so I will add the same name.

Copy the policy Json text from https://docs.microsoft.com/en-us/azure/governance/policy/samples/nsg-on-subnet and paste it at the POLICY RULE below and Save.

At the “effect” part of the Json, change the “deny” to “audit”.

If you search for “NSG” you will see our new policy definition, ready to be assigned.

Click on the definition’s name to open it and press Assign.

I will just target the “ComplianceReport” Resource Group

At the parameters, I added the Resource ID of the NSG, “MyNSG01”

Evaluate the results

To check the compliance, go to Policy – Compliance page and search for nsg. You have to wait for about 15 minutes for the compliance policy to evaluate the resources.

If you search “nsg” you will see that the “Audit NSG on Subnet” policy is 50% compliant. Click on the policy’s name to view more details.

The assignment details page will open where we can see what resources are not compliant.

Click on the three dots (…) next to the non-compliant subnet and select “view compliance details” to check why this resource is not compliant.

The compliance details reports that the value is null and what the required (target) value must be.

If you want to trigger an on-demand compliance check, you need to make a POST request. You can follow my post Validate Azure Resource Move with Postman to create the access Token and then use it to make a POST request to the Resource Group sung this POST:

https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{YourRG}/providers/Microsoft.PolicyInsights/policyStates/latest/triggerEvaluation?api-version=2018-07-01-preview

Source:

https://docs.microsoft.com/en-us/azure/governance/policy/concepts/effects
https://docs.microsoft.com/en-us/azure/governance/policy/samples/nsg-on-subnet
https://docs.microsoft.com/en-us/azure/governance/policy/how-to/get-compliance-data#evaluation-triggers

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 Compliance Report using Azure Policy 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.

Σε προηγούμενο post, Ασφάλισε την Azure SQL Database μέσα σε ένα VNET χρησιμοποιώντας service endpoints, είδαμε πως μπορούμε να χρησιμοποιήσουμε τα Service Endpoints του Azure Virtual Network για να ασφαλίσουμε μια Azure SQL για πρόσβαση μόνο από εσωτερικό δίκτυο.

Σήμερα, το Microsoft Azure, ανακοίνωσε την γενική διαθεσιμότητα του Service Endpoints για MySQL και PostgreSQL. Αυτό δίνει την δυνατότητα να κόψουμε όλη την Public πρόσβαση στις MySQL & PostgreSQL και να επιτρέψουμε μόνο πρόσβαση απο το εσωτερικό μας δίκτυο. Φυσικά μπορεί να οριστεί συγκεκριμένο Subnet ή Subnets. Επίσης δεν υπαρχει επιπλέων χρέωση για την χρήση των Service Endpoint.

Περισσότερα μπορείτε να δείτε στο Microsoft Azure Blog: Announcing VNet service endpoints general availability for MySQL and PostgreSQL

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 MySQL και PostgreSQL με τη χρήση Service Endpoints appeared first on Apostolidis Cloud Corner.

For many companies, a throwback of using Azure SQL was the Public Access. After the latest Azure updates you can use the service endpoints to  Secure your Azure SQL locally inside your vnet! For the time, the feature is available only at the West Central US, West US 2, and East US regions but soon more will follow.

So, lets secure your Azure SQL locally inside your vnet! At the VNET creation blade, select the Microsoft.Sql service endpoint from the list of the available service endpoints.

Then create an SQL Database at the same region,

Next, go to the SQL server firewall settings and turn Off the “Allow access to Azure services”. By doing this you disable the access to the SQL Server using the Public IP.

Click the “Add existing virtual network” and create an access rule, in order to be able to access the SQL Server from your Virtual Network using the service endpoints.

Now lets test. A fast way to test your SQL connectivity from a Virtual Machine on the VNET, without having the SQL management tools, is to open the “ODBC Data Source Administrator” and create a new connection. Add the Azure SQL Server IP

at the next screen enter the username and password of your SQL Server and finally click the “Test Data Source”

Of course we can also connect with the SMSS. Add the SQL Server FQDN, the username and the password

and you are connected, fast and securely!

You cannot yet add your SQL to a subnet, but you secure it’s access inside your VNET! all public access is denied.

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 Secure your Azure SQL locally inside your vnet using service endpoints appeared first on Apostolidis Cloud Corner.