Skip to content

Commit ff52b3c

Browse files
Merge pull request #99420 from surajmb/appgwnsgedits
Changes in AppGW NSG restrictions
2 parents 0fe0ddf + 8f0790f commit ff52b3c

File tree

3 files changed

+34
-9
lines changed

3 files changed

+34
-9
lines changed

articles/application-gateway/application-gateway-faq.md

Lines changed: 25 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -376,6 +376,31 @@ Yes. If your configuration matches following scenario, you won't see allowed tra
376376
- You have an NSG on the application gateway subnet
377377
- You've enabled NSG flow logs on that NSG
378378

379+
### How do I use Application Gateway V2 with only private frontend IP address?
380+
381+
Application Gateway V2 currently does not support only private IP mode. It supports the following combinations
382+
* Private IP and Public IP
383+
* Public IP only
384+
385+
But if you'd like to use Application Gateway V2 with only private IP, you can follow the process below:
386+
1. Create an Application Gateway with both public and private frontend IP address
387+
2. Do not create any listeners for the public frontend IP address. Application Gateway will not listen to any traffic on the public IP address if no listeners are created for it.
388+
3. Create and attach a [Network Security Group](https://docs.microsoft.com/azure/virtual-network/security-overview) for the Application Gateway subnet with the following configuration in the order of priority:
389+
390+
a. Allow traffic from Source as **GatewayManager** service tag and Destination as **Any** and Destination port as **65200-65535**. This port range is required for Azure infrastructure communication. These ports are protected (locked down) by certificate authentication. External entities, including the Gateway user administrators, can't initiate changes on those endpoints without appropriate certificates in place
391+
392+
b. Allow traffic from Source as **AzureLoadBalancer** service tag and Destination and destination port as **Any**
393+
394+
c. Deny all inbound traffic from Source as **Internet** service tag and Destination and destination port as **Any**. Give this rule the *least priority* in the inbound rules
395+
396+
d. Keep the default rules like allowing VirtualNetwork inbound so that the access on private IP address is not blocked
397+
398+
e. Outbound internet connectivity can't be blocked. Otherwise, you will face issues with logging, metrics, etc.
399+
400+
Sample NSG configuration for private IP only access:
401+
![Application Gateway V2 NSG Configuration for private IP access only](./media/application-gateway-faq/appgw-privip-nsg.png)
402+
403+
379404
## Next steps
380405

381406
To learn more about Application Gateway, see [What is Azure Application Gateway?](overview.md).

articles/application-gateway/configuration-overview.md

Lines changed: 9 additions & 9 deletions
Original file line numberDiff line numberDiff line change
@@ -42,9 +42,9 @@ We recommend that you use a subnet size of at least /28. This size gives you 11
4242

4343
#### Network security groups on the Application Gateway subnet
4444

45-
Network security groups (NSGs) are supported on Application Gateway. But there are several restrictions:
45+
Network security groups (NSGs) are supported on Application Gateway. But there are some restrictions:
4646

47-
- You must allow incoming Internet traffic on TCP ports 65503-65534 for the Application Gateway v1 SKU, and TCP ports 65200-65535 for the v2 SKU with the destination subnet as *Any*. This port range is required for Azure infrastructure communication. These ports are protected (locked down) by Azure certificates. External entities, including the customers of those gateways, can't initiate changes on those endpoints without appropriate certificates in place.
47+
- You must allow incoming Internet traffic on TCP ports 65503-65534 for the Application Gateway v1 SKU, and TCP ports 65200-65535 for the v2 SKU with the destination subnet as **Any** and source as **GatewayManager** service tag. This port range is required for Azure infrastructure communication. These ports are protected (locked down) by Azure certificates. External entities, including the customers of those gateways, can't initiate changes on those endpoints without appropriate certificates in place.
4848

4949
- Outbound internet connectivity can't be blocked. Default outbound rules in the NSG allow internet connectivity. We recommend that you:
5050

@@ -53,12 +53,12 @@ Network security groups (NSGs) are supported on Application Gateway. But there a
5353

5454
- Traffic from the **AzureLoadBalancer** tag must be allowed.
5555

56-
##### Allow Application Gateway access to a few source IPs
56+
#### Allow Application Gateway access to a few source IPs
5757

5858
For this scenario, use NSGs on the Application Gateway subnet. Put the following restrictions on the subnet in this order of priority:
5959

60-
1. Allow incoming traffic from a source IP or IP range and the destination as either the entire Application Gateway subnet, or to the specific configured private front-end IP. The NSG doesn't work on a public IP.
61-
2. Allow incoming requests from all sources to ports 65503-65534 for the Application Gateway v1 SKU, and ports 65200-65535 for v2 SKU for [back-end health communication](https://docs.microsoft.com/azure/application-gateway/application-gateway-diagnostics). This port range is required for Azure infrastructure communication. These ports are protected (locked down) by Azure certificates. Without appropriate certificates in place, external entities can't initiate changes on those endpoints.
60+
1. Allow incoming traffic from a source IP or IP range with the destination as the entire Application Gateway subnet address range and destination port as your inbound access port, for example, port 80 for HTTP access.
61+
2. Allow incoming requests from source as **GatewayManager** service tag and destination as **Any** and destination ports as 65503-65534 for the Application Gateway v1 SKU, and ports 65200-65535 for v2 SKU for [back-end health communication](https://docs.microsoft.com/azure/application-gateway/application-gateway-diagnostics). This port range is required for Azure infrastructure communication. These ports are protected (locked down) by Azure certificates. Without appropriate certificates in place, external entities can't initiate changes on those endpoints.
6262
3. Allow incoming Azure Load Balancer probes (*AzureLoadBalancer* tag) and inbound virtual network traffic (*VirtualNetwork* tag) on the [network security group](https://docs.microsoft.com/azure/virtual-network/security-overview).
6363
4. Block all other incoming traffic by using a deny-all rule.
6464
5. Allow outbound traffic to the internet for all destinations.
@@ -70,10 +70,10 @@ For the v1 SKU, user-defined routes (UDRs) are supported on the Application Gate
7070
For the v2 SKU, UDRs are not supported on the Application Gateway subnet. For more information, see [Azure Application Gateway v2 SKU](application-gateway-autoscaling-zone-redundant.md#differences-with-v1-sku).
7171

7272
> [!NOTE]
73-
> UDRs are not supported for the v2 SKU. If you require UDRs you should continue to deploy v1 SKU.
73+
> UDRs are not supported for the v2 SKU as of now.
7474
7575
> [!NOTE]
76-
> Using UDRs on the Application Gateway subnet causes the health status in the [back-end health view](https://docs.microsoft.com/azure/application-gateway/application-gateway-diagnostics#back-end-health) to appear as "Unknown." It also causes generation of Application Gateway logs and metrics to fail. We recommend that you don't use UDRs on the Application Gateway subnet so that you can view the back-end health, logs, and metrics.
76+
> Using UDRs on the Application Gateway subnet might cause the health status in the [back-end health view](https://docs.microsoft.com/azure/application-gateway/application-gateway-diagnostics#back-end-health) to appear as "Unknown." It also might cause generation of Application Gateway logs and metrics to fail. We recommend that you don't use UDRs on the Application Gateway subnet so that you can view the back-end health, logs, and metrics.
7777
7878
## Front-end IP
7979

@@ -161,7 +161,7 @@ To configure a global custom error page, see [Azure PowerShell configuration](ht
161161

162162
You can centralize SSL certificate management and reduce encryption-decryption overhead for a back-end server farm. Centralized SSL handling also lets you specify a central SSL policy that's suited to your security requirements. You can choose *default*, *predefined*, or *custom* SSL policy.
163163

164-
You configure SSL policy to control SSL protocol versions. You can configure an application gateway to use a minumum protocol version for TLS handshakes from TLS1.0, TLS1.1, and TLS1.2. By default, SSL 2.0 and 3.0 are disabled and aren't configurable. For more information, see [Application Gateway SSL policy overview](https://docs.microsoft.com/azure/application-gateway/application-gateway-ssl-policy-overview).
164+
You configure SSL policy to control SSL protocol versions. You can configure an application gateway to use a minimum protocol version for TLS handshakes from TLS1.0, TLS1.1, and TLS1.2. By default, SSL 2.0 and 3.0 are disabled and aren't configurable. For more information, see [Application Gateway SSL policy overview](https://docs.microsoft.com/azure/application-gateway/application-gateway-ssl-policy-overview).
165165

166166
After you create a listener, you associate it with a request-routing rule. That rule determines how requests that are received on the listener are routed to the back end.
167167

@@ -252,7 +252,7 @@ This feature is useful when you want to keep a user session on the same server.
252252

253253
### Connection draining
254254

255-
Connection draining helps you gracefully remove back-end pool members during planned service updates. You can apply this setting to all members of a back-end pool during rule creation. It ensures that all deregistering instances of a back-end pool continue to maintain existing connections and serve on-going requests for a configurable timeout and don't receive any new requests or connections. The only exception to this are requests bound for deregistring instances because of gateway-managed session affinity and will continue to be proxied to the deregistring instances. Connection draining applies to back-end instances that are explicitly removed from the back-end pool.
255+
Connection draining helps you gracefully remove back-end pool members during planned service updates. You can apply this setting to all members of a back-end pool during rule creation. It ensures that all deregistering instances of a back-end pool continue to maintain existing connections and serve on-going requests for a configurable timeout and don't receive any new requests or connections. The only exception to this are requests bound for deregistering instances because of gateway-managed session affinity and will continue to be forwarded to the deregistering instances. Connection draining applies to back-end instances that are explicitly removed from the back-end pool.
256256

257257
### Protocol
258258

66.8 KB
Loading

0 commit comments

Comments
 (0)