2

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
  • Could it be worth posting the endpoints and network security group definitions you have set up? – john Jan 24 '15 at 6:41
  • if this is a federation setup, and you're using the Barracuda as a WAP, what's the need for the ADFS WAP? Also, since the NSGs are stateful, I would have thought you'd only need an ingress NSG. The outbound traffic would be allowed as part of any TCP connection established by the outside world. What are the addresses of your devices and are there any subnets defined in your VNet? – john Jan 25 '15 at 8:35
  • I am using the ADFS WAP as it provides a level of isolation from the ADFS instances (and is generally part of best practice deployments). The WAF is there to provide DDOS/script injection checks that I don't believe that the WAP can provide. The WAP is deployed in the DMZ, the alternative would be to let the WAF send data through to my Private subnet which I don't think is a particularly secure design. – Aidos Jan 25 '15 at 14:15
  • I realise that I've named the VM's in the subnet's the wrong way around in my question - I will edit it to fix. – Aidos Jan 25 '15 at 14:15
0

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.

  • If you think this is along the right lines, I'll update the answer with PowerShell examples to create the entries. – john Jan 25 '15 at 9:24
  • Thanks for your comment John - I'm reasonably familiar with NGS's, my problem is specifically around allowing Internet access into the DMZ subnet I have set up. I have found a way to make it work, by setting the source port to *, however this seems like a cludge. – Aidos Jan 25 '15 at 14:13
  • @Aidos It sounds like you're not allowing enough of the right kind of traffic through? Are you able to run a trace on the client to see what traffic, if any, is blocked? – john Jan 26 '15 at 19:20
  • 1
    SourcePort normally needs to be *, you (normally) never know what the clients use for port. I wouldn't consider that a "cludge". – Trondh Feb 6 '15 at 14:23
  • 1
    no prob Aidos. Glad you got it working :-) – Trondh Feb 20 '15 at 8:46

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.