I will add, for those seeing this question in 2020, that the port range is different for the V1 sku compared to V2 application gateway sku.
If you wish to add a Network Security Group to the subnet which your application gateway resides, you'll need to permit all inbound traffic for the following port ranges:
V1: 65503-65534
V2: 65200-65535
For reference, the Azure Portal will throw the following error if you attempt to assign a NSG to the application gateway subnet, without first permitting the required port ranges (my details have been removed).
Failed to save subnet 'xxxxxxxxxx'. Error: 'Network security group xxxxxxxxxx/providers/Microsoft.Network/networkSecurityGroups/'. xxxxxxxxxx blocks incoming internet traffic on ports 65200 - 65535 to subnet /subscriptions/xxxxxxxxxx/resourceGroups/xxxxxxxxxx/providers/Microsoft.Network/virtualNetworks/xxxxxxxxxx/subnets/xxxxxxxxxx, associated with Application Gateway /subscriptions/xxxxxxxxxx/resourceGroups/xxxxxxxxxx/providers/Microsoft.Network/applicationGateways/xxxxxxxxxx. This is not permitted for Application Gateways that have V2 Sku.'
General instructions:
- Create your Network Security Group. Ensure you create two incoming rules -- (1) to allow all incoming traffic for the applicable port range as defined above, and (2) to allow your necessary application ports, such as
80
and 443
, which are standard HTTP and HTTPS traffic ports. This of course, should match whatever rule/listener configuration you have on your application gateway.
- From the Virtual Networks blade, select your applicable virtual network, then choose Subnets from the sidebar. Then, select your applicable subnet and a configuration panel should appear, which will allow you to assign your NSG to your subnet.
I'll further call attention to a couple tips that might help.
- For the purpose of managing public IP traffic, applying a Network Security Group to the virtual machines defined in your backend pool(s), will not work. Traffic routed to your VM's comes from your application gateway, which will of course, be the IP's of the instances associated with your application gateway, and not the public facing client IPs you're likely trying to target.
- If you're testing a policy, perhaps with your own public IP, its important to note that this will not be reflected if you are trying to access your application from an existing browser session. Calls will continue to work until you either completely close your browser, or otherwise use incognito.
- Assigning a Network Security Group to your application gateway can be performed safely, as it will not cause downtime (unless you forget to create your inbound application rules).