Secure Azure Virtual Network and create DMZ on Azure VNET using Network Security Groups (NSG)

Join the conversation! 20 Comments

1. 

   Peter Reid

   10th of November, 2014 at 6:37 pm

   Perfect, I’ll be using this tomorrow to replace my 2 cloud service and ACL based DMZ

   • 

     Mike

     3rd of January, 2015 at 1:06 am

     This is a great start trying to get acclimated to NSG configuration parameters. Could we expand on this to include load balancers and all the commands to create the outline environment?

     • 

       Andreas Wasita

       15th of January, 2015 at 12:33 pm

       Hi Mike,

       You can create your Load Balancers subnet for example: 10.0.3.0/25. And then you can create NSG Load Balancers subnet for example and then you can configure your rules there.
       Hope it gives some ideas

2. 

   James

   14th of January, 2015 at 2:23 am

   Excellent, however one thing i’m unsure on if you can assist is do you need to put in Inbound and Outbound rules manually? Will it co-match the rules thereby negating the need to put in loads of inbound and outbound rules?

   • 

     Andreas Wasita

     15th of January, 2015 at 1:24 pm

     Hi James,

     What you can do to minimize mundane manual tasks creating NSG rules is using PowerShell to automate.

     Simple example:
     I created App1 NSG with all the rules. Now I want to create App2 NSG with the same rules. I can use the same script and change the Get-AzureNetworkSecurityGroup -Name “App1” instead of “App1” ; I will use $Name instead.

     Then I can do Import-CSV style or $name = Read-Host -Prompt ‘NSG Name:’

     Hope it gives some ideas

3. 

   James

   16th of January, 2015 at 1:03 am

   I’m getting really confused with my rules… I have two subnets call them web and office.
   web -office only SQL and AD ports
   Office to Web open fine…
   in the WEB NSG i have Outbound
   WEB SQL Allow 10.1.1.0/25 1443 10.1.10.0/25 1443 TCP Allow 341
   WEB_Office Deny 10.1.1.0/25 * 10.1.10.0./25 * TCP DENY 600
   and the normal rules

   i haven’t created a Office NSG yet therefore should be allowing all?

   which does deny all except ping however it doesn’t allow SQL through either??

   any thoughts

   • 

     Andreas Wasita

     30th of January, 2015 at 1:03 pm

     @James : Defining outbound NSG rule is a bit tricky. So by default it will allow outbound to :
     1. Internet
     2. Comm to other subnets within your VPC

     My suggestion will be: Take a top to bottom approach ; inbound to outbound approach.
     Define what’s your strategy first and define your inbound rules first before creating your outbound. If you can secure your subnets using inbound only, even better. Usually I will block all outbound Internet connection except the DMZ and use all inbound rules before using outbound rules.

     I won’t be able to help with your NSG in detail but ping is using ICMP not TCP

4. 

   scott SCiarrino

   22nd of January, 2015 at 3:35 am

   This is great, but have a few questions.
   1. could this setup be PCI compliant?
   2. can this be done between vnet or have to be all in 1 vnet.
   3. so you can do egress filtering on traffic to the internet.
   4. can this be done at a machine level not network level?
   THANKS!!!

   • 

     Simon Waight

     28th of January, 2015 at 9:19 am

     Scott, here we go:

     1) It depends on what “PCI compliant” actually means in this context. This is a fairly wide area so it would be good if you have a specific area you are referring to.
     2) At the moment NSGs are bound to a single VNet.
     3) Yes. The default INTERNET tag can be used to filter traffic to / from non-VNet sources.
     4) Yes. You can apply an NSG at a Machine or Subnet level – call Get-AzureVM first and pipe to Set-AzureNetworkSecurityGroupConfig to apply to a VM (see the usage samples here on the announcement post).

5. 

   heto14

   23rd of January, 2015 at 12:44 am

   We observed a strange behaviour: Ping to a server in a subnet with an NSG only allowing HTTPS (443) as incoming traffic is not possible. That is ok and correct. When then adding a rule that allows any incoming traffic (source address * and source port * and protocol *) Ping is possible. When removing the “any incoming traffic” rule ping remains possible. Any idea why? And any idea how to create a rule for ping?

   • 

     Simon Waight

     23rd of January, 2015 at 9:02 am

     It can take a little while for the NSG to propagate to the hosts in the subnet so it might be worth waiting for a while and then checking again. I’d recommend you check the default rules for a new subnet by using the Get-AzureNetworkSecurityGroup Cmdlet and pass it the -Detailed Flag (see example at bottom of the page linked to). Then run the same for your modified NSG and see what differences there are. You can then remove any rules that shouldn’t be there.

     • 

       heto14

       23rd of January, 2015 at 7:29 pm

       Thanks for your answer. I’m confused after removing the complete NSG from the subnet pinging is still possible (when there was a “allow all” rule before), buta fter rebooting the server pinging was stopped.

6. 

   Paul Carmichael

   4th of May, 2015 at 10:38 pm

   I understand that NSG allows for basic access control lists but what is your recommendation if you want to have packet inspection (ie a real firewall)?

   • 

     Simon Waight

     7th of May, 2015 at 12:44 pm

     Hi Paul – good timing! Microsoft just announced the availability of User Defined Routes and the upcoming support of vendor-provided Firewall appliances that can be IP forwarded to.
     This session at Ignite is heavy on Vendor demos: https://channel9.msdn.com/Events/Ignite/2015/BRK2460 (once the video is available) and additional documentation on UDR and IP forwarding can be found here: http://azure.microsoft.com/en-gb/documentation/articles/virtual-networks-udr-overview/ (note this isn’t in every Azure Region just yet). You can still use NSGs if you wish, but the combination of UDR and IPF will probably solve most situations.

7. 

   Suresh Parmar (@sparmar2000)

   25th of May, 2015 at 12:32 pm

   Hi Andreas

   Fantastic blog… 🙂

   I am trying to replicate using;
   #Create a Network Security Group
   New-AzureNetworkSecurityGroup -Name “PER_NSG” -Location “West Europe” -Label “Perimeter NSG H3QA1 Net”
   #Add, Update Rules to a NSG
   Get-AzureNetworkSecurityGroup -Name “PER_NSG” | Set-AzureNetworkSecurityRule -Name HTTPInternet-DMZ -Type Inbound -Priority 347 -Action Allow -SourceAddressPrefix ‘*’ -SourcePortRange ‘*’ -DestinationAddressPrefix ‘10.4.2.0/24′ -DestinationPortRange ’80’ -Protocol TCP
   Get-AzureNetworkSecurityGroup -Name “PER_NSG” | Set-AzureNetworkSecurityRule -Name HTTPSInternet-DMZ -Type Inbound -Priority 349 -Action Allow -SourceAddressPrefix ‘*’ -SourcePortRange ‘*’ -DestinationAddressPrefix ‘10.4.2.0/24’ -DestinationPortRange ‘443’ -Protocol TCP
   Get-AzureNetworkSecurityGroup -Name “PER_NSG” | Set-AzureNetworkSecurityRule -Name RDPInternet-DMZ -Type Inbound -Priority 345 -Action Allow -SourceAddressPrefix ‘*’ -SourcePortRange ‘62970’ -DestinationAddressPrefix ‘10.4.2.0/24’ -DestinationPortRange ‘62970’ -Protocol TCP
   Get-AzureNetworkSecurityGroup -Name “PER_NSG” | Set-AzureNetworkSecurityRule -Name RDP2Internet-DMZ -Type Inbound -Priority 344 -Action Allow -SourceAddressPrefix ‘*’ -SourcePortRange ‘59887’ -DestinationAddressPrefix ‘10.4.2.0/24’ -DestinationPortRange ‘59887’ -Protocol TCP
   #Associate a NSG to a subnet
   Get-AzureNetworkSecurityGroup -Name “PER_NSG” | Set-AzureNetworkSecurityGroupToSubnet -VirtualNetworkName ‘H3QA1’ -SubnetName ‘A-H2PE01’

   but…after running the script

   1. Cannot telnet to port 80 or 443
   2. RDP to my VM stops

   when I;
   #Remove a NSG from the subnet
   Get-AzureNetworkSecurityGroup -Name “PER_NSG” | Remove-AzureNetworkSecurityGroupFromSubnet -VirtualNetworkName ‘H3QA1’ -SubnetName ‘A-H2PE01’

   I can RDP to my VM’s

   Can you help?

8. 

   Suresh Parmar (@sparmar2000)

   26th of May, 2015 at 7:04 am

   Ah! Fixed. Silly me, the RDP port number is 3389!

9. 

   ronit

   3rd of December, 2015 at 5:56 pm

   I am using azure backup services for my servers in azure. And I have
   applied NSG to the subnet and blocked the INTERNET where my VMs are deployed.

   But azure backup extension need access to azure datacenter IPs
   for successful backup.I have downloaded IPs from this link

   http://www.microsoft.com/en-us…
   .Microsoft recommend to create a rule in
   NSG and allow the access to all IPs from server.

   I am using this rule: Get-AzureNetworkSecurityGroup -Name
   “AZURE_BACKUP” | Set-AzureNetworkSecurityRule -Name “Allow
   internet” -Type Outbound -Priority 347 -Action Allow -SourceAddressPrefix
   ‘10.0.0.0/29’ -SourcePortRange ‘*’
   -DestinationAddressPrefix ‘??????’ -DestinationPortRange ‘*’ -Protocol ‘*’.

   But the problem is that I don’t want to run this command for hundred of times
   as there are hundreds of IPs are there.I want to run this command once and it
   fetch all the IPs from xml file and allow access to following IPs.

   Is it possible.

   • 

     Simon Waight

     8th of December, 2015 at 9:59 am

     Ronit, theoretically you could script the creation of the rules based on an input CSV, however you should be aware that there is limit of 200 rules per NSG and you can only associate 1 NSG with a subnet, VM or NIC at once. There’s no easy solution to your situation using NSGs if you are blanket blocking all ports bound the Internet. VPN and / or ExpressRoute would provide alternative routes to public Azure endpoints but they may not play a part if your environment. As NSGs are relatively new hopefully we’ll see some ability to allow traffic to Azure IPs using a Tag. In the meantime perhaps you want to look at standing up a virtual firewall appliance and using UDR and IP Forwarding to force traffic via that and utilise it to achieve what you are today with NSGs.

     • 

       Ronit

       8th of December, 2015 at 2:11 pm

       Thanks a lot Simon

10. 

    joanmartin1185

    28th of April, 2017 at 4:09 pm

    Nice post. Thanks for sharing this informative post

Comments are closed.