I have the next azure setup:
Application gateway balancer with it's own vnet .
Two vms in Application gateway backend pool which have their own vnet and a network security group applied to the vms.
Main problem:
How can I instruct the network security group to allow http/https traffic only from the application gateway ?
What I've tried :
a) added inbound rule in network security group with source having tag AzureBalancer . Is not working . Probes are telling me that the vms are in an unhealthy state.
b) I've peered the two vnets and I've added an inbound rule having source tag VirtualNetwork . Same as above, probes telling me that the vms are in an unhealthy state.
c) I've added an inbound rule in nsg to allow traffic only from the public ip of the application gateway. This is working fine , probes are seeing the vms in a healthy state.
The only problem is that the public ip address of the application gateway is dynamic and it cannot be made static.
So when the ip will change my rule will not work.
I am curios to find out how to make this setup works.
All the examples I saw on azure documentation site are with one single vnet with multiples subnets.
If there is an NSG on Application Gateway subnet, port ranges 65503-65534 should be opened on the Application Gateway subnet for Inbound traffic. These ports are required for the backend health API to work.
I've copied the above sentence verbatim from this document: https://learn.microsoft.com/en-us/azure/application-gateway/application-gateway-diagnostics
... as I ran into the same issue. After adding the above to my NSG, my health-check probes worked.
The only problem is that the public ip address of the application
gateway is dynamic and it cannot be made static.
You are right, for now, we can't set application gateway public to static.
And we can't add NSG inbound rules with application gateway FQDN.
As a workaround, we can use internal IPs as backend pool members, connect them with vnet peering or VPN gateway.
Related
In the documentation for Azure ContainerApps Ports and IP Addresses section it indicates that the
Outbound public IP
Used as the "from" IP for outbound connections that leave the virtual network. These
connections aren't routed down a VPN. Using a NAT gateway or other proxy for outbound
traffic from a Container App environment isn't supported. Outbound IPs aren't guaranteed
and may change over time.
The inbound IP for a ContainerApps Environment is fixed. Azure Container Instances (not ContainerApps) on the other hand seem to have documented capability to configure a static outbound IP via NAT Gateway.
Is there a way to configure a static outbound IP for Azure ContainerApps as well?
If not, which alternate deployment models for a long-running background service are recommended? The requirement is that an external service can count on a fixed outbound IP (or very small range, not the entire DataCenter IP ranges) for whitelisting.
** EDIT - It seems that NAT on VNet is not yet supported on ACA - https://github.com/microsoft/azure-container-apps/issues/522
way to configure a static outbound IP for Azure ContainerApps as well?
No, we can't configure outbound public IP via container apps; that information is there in the official documentation documentation itself.
try this out, Create outbound application rule on the firewall
using below command
az network firewall application-rule create
It will create an outbound rule on the firewall. This rule allows access from the subnet to Azure Container Instances.
HTTP access to the site will configure through egress IP address from Azure Container Instances.
i have found one blog refer this
We deploy to Azure app services and to ensure secure traffic between each service they are configured with out bound traffic on a virtual network subnet. Each app service must have it's own subnet, which is understandable, but to allow the app services to communicate we are having to add inbound ip restrictions for each subnet, on each app service.
As all the subnets for all the app services within an environment are on the same virtual network we were expecting the traffic to route between the subnets. In that way by connecting each app service to an out bound subnet and allowing traffic back in on that subnet it would also allow traffic from the other subnets of the virtual network.
I've read here Azure: Routing between subnets a response that state "Azure routes traffic between all subnets within a virtual network, by default. You can create your own routes to override Azure's default routing." but that does not appear to be happening for us.
Is there a setting we need to change or a route that must be added to allow us to have a single inbound rule from the virtual network that allows all traffic from all subnets of the virtual network.
We are splitting our process into micro app services but this is making security of inter-app traffic complex as each time we add an app service we must update all others with an additional inbound rule before it can communicate.
We also have a similar issue with managing access to the azure sql database where we have connected the sql to a subnet in the virtual network but traffic from the app services cannot access over that subnet.
Any advice please?
We are using Azure Application Gateway for our site, and we are getting few people scraping our site. We want to block their IP at gateway level, as we don't want to configure the same blocks in every web service.
We can not find the way of blocking IPs using only the gateway or its virtual network. Had anybody the same problem and can illuminate our path?
You could deploy Application Gateway in a virtual network. If so, you will have a dedicated subnet for this Application Gateway. This subnet can only contain Application Gateways. You could associate an NSG to this subnet. If so, you could restrict inbound and outbound traffic from this Application Gateway subnet via inbound or outbound security rules in NSG. In this case, you could add an inbound security rule to backlist your clients' IP.
Refer to DOC, Note:
Network Security Groups (NSGs) are supported on the application
gateway subnet with the following restrictions:
Exceptions must be put in for incoming traffic on ports 65503-65534
for the Application Gateway v1 SKU and ports 65200 - 65535 for the v2
SKU. This port-range is required for Azure infrastructure
communication. They are protected (locked down) by Azure certificates.
Without proper certificates, external entities, including the
customers of those gateways, will not be able to initiate any changes
on those endpoints.
Outbound internet connectivity can't be blocked.
Traffic from the AzureLoadBalancer tag must be allowed.
Hope this helps.
I have provisioned App Gateway with WAF V2 SKU. Then, I have configured back-end pool to point to WebApp and added IP restrictions to allow only traffic from WAF IP. Then, i am attempting to add NSG to the provisioned Subnet to further restrict traffic to the Frontend IP address. I am getting an error (see below). Per Application Gateway FAQ this should be possible, but having trouble. Here is are the details of the deployment error:
Network security group /subscriptions/49c19f96-135d-4599-ae34-fd9087ce2bf8/resourceGroups/dbt-sc-platform-rg/providers/Microsoft.Network/networkSecurityGroups/BannerCIDRNsg blocks incoming internet traffic on ports 65200 - 65535 to subnet /subscriptions/49c19f96-135d-4599-ae34-fd9087ce2bf8/resourceGroups/dbt-sc-platform-rg/providers/Microsoft.Network/virtualNetworks/dbt-sc-platform-rg/subnets/default, associated with Application Gateway /subscriptions/49c19f96-135d-4599-ae34-fd9087ce2bf8/resourceGroups/dbt-sc-platform-rg/providers/Microsoft.Network/applicationGateways/dbt-sc-appgw. This is not permitted for Application Gateways that have V2 Sku.
The error message displays that you need to add incoming internet traffic on ports 65200 - 65535 to subnet-default in your Network security group-BannerCIDRNsg.
Per Application Gateway FAQ, you can whitelist Application Gateway access to a few source IPs.
This scenario can be done using NSGs on Application Gateway subnet. The following restrictions should be put on the subnet in the listed order of priority:
Allow incoming traffic from source IP/IP range.
Exceptions must be put in for incoming traffic on ports 65503-65534
for the Application Gateway V1 SKU and ports 65200 - 65535 for the V2
SKU. This port-range is required for Azure infrastructure
communication. They are protected (locked down) by Azure certificates.
Without proper certificates, external entities, including the
customers of those gateways, will not be able to initiate any changes
on those endpoints.
Allow incoming Azure Load Balancer probes (AzureLoadBalancer tag) and
inbound virtual network traffic (VirtualNetwork tag) on the NSG.
Block all other incoming traffic with a Deny all rule.
Allow outbound traffic to the internet for all destinations.
I want to add on #Nancy's answer, that actually, as per the documentation, there is no need to allow traffic from Any protocol. Allowing TCP traffic is enough.
There is also no need to allow traffic from Any source, it is sufficient to allow traffic from GatewayManager service tag.
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.
So, I created the security rule as follows:
It should also be noted that:
These ports are protected (locked down) by Azure
certificates. External entities, including the customers of those
gateways, can't communicate on these endpoints.
I was getting the error message "Subnet associated to gateway with v2 sku" when trying to associate a subnet containing a Gateway V2 WAF to an existing NSG.
Strangely though it was no problem navigating to the VNET -> SubNet and after clicking the given SubNet then associating the NSG to that SubNet.
To associate NSG to the subnet containing an application gateway, allow traffic from
source: 'GatewayManager', port: Any to Destination: 'GatewayManager' service tag, Destination port: 65503-65534
Traffic from the AzureLoadBalancer tag with the destination subnet as Any must be allowed.
Note: just be cautious that you don't add deny rule before these inbound rules, so give them a low priority no, to avoid accidental misconfiguration
Also,
Outbound Internet connectivity can't be blocked
Reference : https://learn.microsoft.com/en-us/azure/application-gateway/configuration-infrastructure#network-security-groups
When I try to execute New-AzureRmApplicationGatewayIPConfiguration to create an application gateway, I get an exception:
Subnet xxx cannot be used for application gateway yyy since subnet is not empty.
I encountered this error when I tried to add the application gateway to the same subnet as the backend servers.
Why is this not an option? Does each gateway require a separate subnet? What is the recommended configuration?
Related questions:
The documentation says backend servers can be added when they belong to the virtual network subnet. How can a back-end server belong to the virtual network subnet of the application gateway if the application gateway must be in a separate subnet?
How can the application gateway be configured without requiring a public IP address on the backend servers?
The application gateway must be in a subnet by itself as explained in the documentation, hence the reason it is not an option. Create a smaller address space for your application gateway subnet (CIDR 'x.x.x.x/29') so you're not wasting IP addresses unnecessarily.
It's a good practice to strive for a multi-tier network topology using subnets. This enables you to define routes and network security groups (ie: allow port 80 ingress, deny port 80 egress, deny RDP, etc.) to control traffic flow for the resources in the subnet. The routing and security group requirements for a gateway are generally going to be different than routing and security group requirements of other resources in the virtual network.
I had the same issue, so my virtual network was 10.0.0.0/24 which was not allowing me to create a separate subnet. I solved the issue as we added another address space into the azure virtual network e.g. 10.10.0.0.24, then created a new subnet so that the application gateway was happy to work with the backend servers.