Security – Allowing Internet traffic into DMZ using Azure Network Security Group

azuredmznetworkingSecurity

I am trying to create a simple DMZ using Azure Network Security Groups, using a Barracuda WAF as the public entrypoint into the DMZ, however I am having some trouble allowing internet traffic to access the Barracuda (and then be forwarded on to my Internal Load Balancer for my Application Servers).

What should I be using for the SOURCE and DESTINATION IP prefixes? I have tried:

  • Source: 0.0.0.0/0 Destination: internal IP of Barracuda
  • Source: INTERNET Destination: internal IP of Barracuda
  • Source: Public IP of Barracuda Destination: internal IP of Barracuda
  • Source: 0.0.0.0/0 Destination: public IP of Barracuda

I have also tried changing the priority of the entry to be 100 as well as 1000 (all others are 900 – 500).

I have removed all of the default endpoint configurations on the Virtual Machine for the Barracuda (as I have found that these seem to override the Network Security Group).

The network definitely works with the Barracuda when I don't have the Network Security Group installed, but I am wanting to use a Network Security Group to make sure I have a "secure as possible" DMZ.

Endpoints

Name     | Type     | Prty | Source IP | Port | Dest IP       | Port | Protcl | Access
DMZ NSG:  
Internet | Inbound  | 100  | INTERNET  | 443  | 10.106.164.20 | 443  | TCP    | Allow
ADFS-WAP | Outbound | 900  | 10.0.20.0 | 443  | 10.0.1.10     | 443  | TCP    | Allow
Internal NSG:  
ADFS     | Inbound  | 900  | 10.0.20.0 | 443  | 10.0.1.10     | 443  | TCP    | Allow

Best Answer

I'm pretty new to Azure, but I'll try and help. I've done a bit of reading on NSGs, but not used them in practise.

  • NSGs apply to a VM or a Subnet.
  • NSGs currently only apply to the primary NIC of a VM.
  • As you said, the VM endpoints are not compatible with NSGs.

If your Barracuda WAP has two interfaces, I'm not sure how that would work with NSGs. I don't think NSGs give you the flexibility you're after.

With this in mind, I would recommend having two subnets, DMZ and internal. For example, SUBNET1 could be 10.0.1.0/24, SUBNET2 10.0.2.0/24. You then apply your NSG to the subnets instead of the VMs, giving you the flexibility to add more services without creating new NSGs for each VM. You can just add entries to the existing NSGs if needed.

For the DMZ subnet you have an inbound rule that allows INTERNET:443 -> SUBNET1:443 (10.0.1.0/24), and for the internal subnet you have have and inbound rule also: SUBNET1:443 (10.0.1.0/24) -> SUBNET2:443 (10.0.2.0/24). The NSG are stateful, so if an inbound connection is initiated, the corresponding outbound traffic for that connection is also allowed.

Related Topic