How to Protect Web App using Virtual Network - azure

I am trying to protect a web app using a virtual network. So I created network resources as this link describes. Then I created an application gateway as per the instruction of this link.
Finally I did what this link says to configure the web app.
However, when I went to my web app, under the networking I didn't see it being connected to any VNet. It was saying the VNet doesn't have any Virtual Network Gateway. So I created a VNG and then I went back to the web app, networking and connected it to the VNet.
Now under the Application Gateway health prob I expect the health probs to be successful. But I keep getting a 404. I checked my web app log and no request seems to be coming in.
In a nutshell I have the following:
Virtual Network (VNet): 10.0.0.0/16
Virtual Network Gateway (VNG): 10.1.0.0/24
Application Gateway (AG): this has a public IP. I created a CName on mydomain.com to point to this AG
VNet has 3 subnets: Backend SN(10.0.1.0/24), App Gateway SN(10.0.2.0/24) and another called Gateway SN(10.0.0.0/24)
The AG, has a backend pool, HTTP Settings and a Frontend IP
The AG backend pool points to the web app service
The AG HTTP Settings points to port 80, and the Pick hostname from backend address is checked
The AG also has Listener where the hostname is set to mydomain.com
I believe at this stage if I go to mydomain.com then I should see my web app. But I get the error:
502 - Web server received an invalid response while acting as a gateway or proxy server.
There is a problem with the page you are looking for, and it cannot be displayed. When the Web server (while acting as a gateway or proxy) contacted the upstream content server, it received an invalid response from the content server
And the probs still get 404.
Can someone help please?

What fixed it for me was that I need to make sure -PickHostNameFromBackendAddress is set when doing New-AzureRmApplicationGatewayBackendHttpSettings.

Related

Stopping Default IIS website causes Azure Application Gateway '502 Bad Gateway' Error for ALL websites in IIS

I'm having an issue with hosting multiple .NET websites on Windows Server/IIS and Azure Application Gateway.
We host multiple sites on a single Azure Windows VM running IIS, sitting behind Azure Application Gateway WAFv2. The VM is connected to App Gateway using a backend pool configured to point to the private IP of the VM, with the VNets peering configured between the App Gateway and VM VNets.
When I stop the default website in IIS, ALL websites then return a '502 Bad Gateway' error from Azure Application Gateway, and the backend health status changes to 'Unhealthy' for the backend pool where the VM resides.
Can anyone tell me why stopping the Default site would cause Application Gateway to error for all sites?
EDIT:
Screenshot of IIS bindings as requested
EDIT 2: Apparently I can't answer my own question, however after working through this with our CSP I have the answer. By default the App Gateway Backend Health check looks at the default IIS site. If you stop that then the Backend Health Check fails and goes Unhealthy. At this point APP Gateway will no longer even ATTEMPT to route any requests, regardless of URL to that backend pool.
If the application gateway has no VMs or virtual machine scale set configured in the back-end address pool, it can’t route any customer request and sends a bad gateway error.
Following the below command to show back-end address pool JSON result.
Get-AzApplicationGateway -Name "SampleGateway" -ResourceGroupName "ExampleResourceGroup"
Here is an official guideline for troubleshooting the 502 error.
https://learn.microsoft.com/en-us/azure/application-gateway/application-gateway-troubleshooting-502#overview
Also, here is a simple troubleshooter.
https://support.microsoft.com/en-us/help/4504111/azure-application-gateway-with-bad-gateway-502-errors
If I were to try and troubleshoot this, I would likely start with a brand new "test" instance of IIS and set up a reverse proxy on port 80 whose only job is to listen to incoming requests to port 80. Those requests would then be forwarded by your reverse proxy to your actual websites bound to different ports (e.g. 81, 82, 83, etc).
The idea here is to have all of your websites running on different ports such that when you stop one of your sites, the others continue to run without a problem.
Given your setup with up to 40 sites hosted in a single instance of IIS, I would only attempt this type of troubleshooting with a brand new "test" instance of IIS.
Create a brand new "test" instance of IIS.
Create a reverse proxy. To do this, create a new site and name it (e.g. rev-proxy) and give it a binding of port 80.
Deploy one actual site (e.g. myfirstsite). Give it a port binding of something other than 80 (e.g. 81).
Double click your rev-proxy site and add a URL Rewrite -> Inbound Rules -> Blank rule. See attached picture. Add a rule such that when a user requests "myfirstsite" that request is forwarded onto port 81. Use the "Test Pattern" button to test your pattern. The image is only a suggestion and your pattern should correspond to the URL your users are using to request your site and not necessarily to the name you give your site in IIS.
An example of a reverse proxy with a URL Rewrite
Found the answer to this after many months of messing about!
With Azure Application Gateway, the default health probes for each backend pool ping and look for a response on the configured IP address or FQDN in the backend pool itself.
In my case this is set to the local IP address of the Virtual machine (when I configured this 18-24 months ago I recall our Azure CSP telling me there was a bug with using the FQDN in the backend pool configuration).
This means, that when the Health Probe is attempting to communicate with the VM, the Default Website in IIS is the only thing configured to respond to any requests on this IP address.
If you stop the Default Site, the Health Probe gets no response to it's requests a the Backend Pool status goes to Unhealthy as you would expect.
The really interesting thing here is that as soon as the Backend Pool Health Probe status goes Unhealthy, Azure Application Gateway ceases to even attempt to route any traffic to the affected backend pool. Instead it immediately reports the 502 Bad gateway error, and will continue to do so until the Health Probe status is corrected and goes back to healthy!

Azure App Service behind Azure Application Gateway

I'm trying to serve multiple Azure App Services behind an Application Gateway. These services should only be reachable through the application gateway endpoint. To achieve this, I've done the following:
Added a VNet
Added a subnet, and added all app services to it
Added an application gateway with appropriate rules for pointing to the app service
Added access restrictions to the app service to only allow the subnet of the application gateway, and the public IP of the application gateway
The health probe of the application gateway indicates the service is healthy (and thus reachable), but when I try to make a request to the service trough the gateway using Postman, I get a 403 IP forbidden error. However, when I add my local IP as an allowed IP address to the app service, the request comes through just fine
From what I've read online, adding the public IP of the gateway should be sufficient for allowing access through the gateway, but it seems that requests from my local machine are blocked. Am I getting something fundamentally wrong here?
Edit: I also tried assigning a front-end private IP address to the gateway and adding access for that in the app service, but that also did not work
Edit 2: My configuration
Access restrictions for app service:
access restrictions
Backend pool:
Backend pool
HTTP settings:
HTTP settings
Listener:
Listener
Rule:
Rule
From your description "Added a subnet, and added all app services to it", I assume that you are meaning integrating app with Azure VNet or enable the service endpoint with Microsoft.Web for the subnet. If so, you could remove them. Both are useless in this scenario.
To restrict the access through the gateway, you only need to add the frontend IP address to the Azure App Service access restrictions. For more details, you could refer to this blog https://www.cloudmanav.com/azure/restricting-appservice-accessible-via-appgateway/#
If you have NSG associated with the subnets, you could follow the prerequisites here
https://learn.microsoft.com/en-us/azure/application-gateway/configuration-overview#network-security-groups-on-the-application-gateway-subnet
Edit
You may have redirection configured on your app service or have Azure Active Directory authentication, which causes the redirection. So when redirection happens, the client makes the request directly to app service URL Path contoso.azurewebsites.net/xxx instead of going through the application gateway URL path contoso.com/xxx.
To fix it, you could use a custom domain name to pass the same host name that the application gateway receives to the app service as well, instead of doing a host override. Get more details about this solution here.

Azure application Gateway WAF

I am trying to configure Azure application gateway WAF with a backendpool set to a VM in a different Azure tenant using its public IP address on port 443. All the SSL certificates are configured properly. However, I keep getting following error while browsing the site via WAF.
502 - Web server received an invalid response while acting as a gateway or proxy server.
I have confirmed that the NSG is on the mentioned back-end VM is allowing all traffic on port 443. What could be going wrong here?
Generally, you can check the status of Backend health in the monitoring of Application Gateway and compare with the DETAILS referring to these possible reasons on your side.
NSG, UDR or Custom DNS is blocking access to backend pool members.
Back-end VMs or instances of virtual machine scale set are not responding to the default health probe.
Invalid or improper configuration of custom health probes.
Azure Application Gateway's back-end pool is not configured or empty.
None of the VMs or instances in virtual machine scale set are healthy.
Request time-out or connectivity issues with user requests.
For each reason, you can get a solution from that link. I think you could make sure you can directly access the backend with public IP from one tenant to another tenant. Then if you have an NSG in the app gateway subnet, you must include exceptions for incoming traffic on ports 65503-65534 for the Application Gateway v1 SKU, and ports 65200-65535 for the v2 SKU. You could get more details here. You could also whitelist the app gateway public IP address in the NSG of backend VM.

Application Gateway 502 error when configuring it for Azure Web App

Scenario:
Configured Azure Application Gateway to route traffic to different Azure Web Apps to leverage the Web Application Firewall (WAF).
Initial configuration worked fine except that the final URL in the browser is the {mysite}.azurewebsites.net. I want this to be the custom domain name {subdomain}.{mysite}.com. This was configured by having the backend pool bound to an app service. Changing it to FQDN is not working. Screen shots below.
CNAME is already pointing to the gateway.
Desired result
When someone hits {subdomain}.{mysite}.com (which is already configured to point to the gateway) I should get {subdomain}.{mysite}.com not {mysite}.azurewebsites.net
Current setup:
The gateway is configured with a multi-site listener with its rule pointing to a backend pool and also bound to the http setting.
Listener is listening on {subdomain}.{mysite}.com
Backend pool config
Probe config
Http setting config
The following links provide some partial answers/configurations but none of them worked for me.
Application Gateway - 502 error
https://learn.microsoft.com/en-us/azure/application-gateway/troubleshoot-app-service-redirection-app-service-url
https://learn.microsoft.com/en-us/azure/application-gateway/create-web-app
UPDATE
Here are a list of steps used to configure an azure app service with a custom domain behind the Azure Application Gateway and WAF (Web Application Firewall) using the azure portal UI.
Configure a Backend pool with target pointing to your App Service.
Configure Health Probe with the following settings
Protocol: HTTP or HTTPS
Host: {appservice}.azurewebsites.net
Path: /
Configure Http setting
Use App Service unchecked.
Use custom probe checked.
Pick host name from backend address unchecked (you might have to check this to configure the rule and then uncheck it).
Configure listener
HostName: {subdomain}.{domain}.com (your domain)
Configure basic rule
Bind it to the appropriate http setting, backend pool and listener
Caveat: If there are no http settings with Pick host name from backend checked, you might need to change it, attach it, and then remove that flag again.
Probably, you get a 502 error because you change to FQDN subdomain.mysite.com in the targets of backend pool. However, In this scenario, you have not changed the custom domains in your web app service, you only could access the web site via the default domain mysite.azurewebsites.net. I suggest changing back to the App service in the targets.
Initial configuration worked fine except that the final URL in the
browser is the {mysite}.azurewebsites.net.
Please check if you have an HTTPS Only setting ON in the Custom domains of web app service. This will redirect all Http to Https. For me, usually, it will cause the final URL in the browser is the mysite.azurewebsites.net.
Update
If you have no HTTPS Only on, this issue may happen due to the following main reasons:
You have redirection configured on your App Service. Redirection can be as simple as adding a trailing slash to the request.
You have Azure AD authentication which causes the redirection.
You have enabled “Pick Host Name from Backend Address” switch in the HTTP settings of Application Gateway.
You don’t have your custom domain registered with your App Service.
This issue can be resolved by not having a redirection on the Application side, however, if that’s not possible, you can follow this solution to resolve it.
Register the domain subdomain.mysite.com to the custom domain list of the App Service. For more information, see Map an existing custom DNS name to Azure App Service.
Once that is done, your App Service is ready to accept the hostname subdomain.mysite.com. Now change your CNAME entry in DNS to point it back to Application Gateway’s FQDN. For example, appgw.eastus.cloudapp.azure.com.
Uncheck the checkbox Pick Hostname from Backend HTTP Settings in probe settings. In the hostname field of the probe, enter your App Service's FQDN mysite.azurewebsites.net as the probe requests sent from Application Gateway will carry this in the host header.
Uncheck the checkbox Pick Hostname from Backend Address in your Application Gateway’s HTTP settings.
Associate the custom probe back to the backend HTTP settings and verify the backend health if it is healthy.
Once this is done, Application Gateway should now forward the same hostname subdomain.mysite.com to the App Service and the redirection will happen on the same hostname.

URL rewrite configuration on Azure

I have WAF, Application Gateway and a VM in place in Azure cloud. I have deployed an application in VM, which is running on tomcate and on port 8280.
I have domain name www.abc.com. In DNS entry, www.abc.com is pointing to my Azure App Gateway on port 80.
I am able to access the my application using IP and port. for example:-
http://X.X.X.X:8280/MyApps/page1 and http://X.X.X.X:8280/MyApps/page2.
I am trying to configure App Gateway, so that when I try to open using domain name. My requirement is when I hit www.abc.com, it should redirect to URL www.abc.com/page1. I tried to setup the listener with basic type and also path based. But no success. When I try to hit www.abc.com, it throws error:
502 - Web server received an invalid response while acting as a gateway or proxy server.
The 502 error always shows that there is a firewall restiction from your application gateway instance to your backend VM. You can verify if there are blocking the traffics in the NSG associated with your application gateway subnet or VM subnet. Also, this might be caused by inproperly configuring the custom health probe. You also can get more reasons from this doc.
Moreover, you can confirm you have set the url-based path correctly. Pay attention to the path and port.

Resources