I've read through the link below and extended the timeout, disable compression on the Origin/Azure Front Door and a Rules Set rule to remove accept-encoding from the request for byte range requests. However, I am still getting these random 503 errors or blank pages.
https://learn.microsoft.com/en-us/azure/frontdoor/front-door-troubleshoot-routing
In my web app, I've added the custom domain (app.contoso.com) with my own certificate.
And in my Front door, I've added my custom domain (app.contoso.com) with my own certificate and set up a backend pool and a routing rule.
And in the update backend, I've left the backend host header empty as I would like it to be able to redirect to the custom domain instead of showing the web app url.
And in my routing rule, I've set the following
I've followed the instruction closely provided from Azure but still getting random 503 Errors or Blank Page from Azure Front Door. And I can confirm that my Web app (contoso.azurewebsites.net) is working when I am getting a 503 errors or blank pages from the custom domain from front door. I've also ensure I used the same SSL certificate on the web app and front door custom domain.
In my DNS, I've mapped the following
app.contoso.com CNAME contoso.azurefd.net
Is there anything I missed out or does anybody have a solution to this?
Follow up
I've tried to enable and disable the certificate subject name validation and change the send/receive timeout from 30 to 240 or from 240 to 30 but still getting the same issues.
Update: It giving blank page or 503 error (see screenshot below)
I have FrontDoor setup in front of multiple backend Web App. I've noticed there's a number of random 503 errors each day. The requests themselves are valid, and retrying generally works, however, the initial request that fails is not hitting the backend Web App. The backend health at the times of the errors are also 100%, and it can't be a timeout because the error is immediate (timeout is also extended to 240 seconds). It seems like FrontDoor itself is having some kind of health issue, but there's no health issues mentioned.
I have observed what I thought were random 503 errors from front door, and eventually narrowed it down to a particular set of circumstances - in the Azure portal, the App Service Client Certificates mode was set to Required or Allow, and the request was an HTTP POST with sizes over 100KB.
My experience was that problem is not in Front Door - it was just reporting the problem. The issue is that the application hosted by the Azure App Service never receives the request that is sent by Front Door, and therefore doesn't respond - leading to a 503 timeout. Increasing the timeout in Front Door won't solve the problem.
From what I've read the underlying cause is that "when the server sends the SSL renegotiation request the client has already sent too much data for the server to buffer before it can receive the SSL renegotiation response" (quoted from here: https://github.com/dotnet/runtime/issues/17336)
There are a couple of workarounds which may help in your scenario involving setting ServicePointManager.Expect100Continue = true (from here https://github.com/dotnet/runtime/issues/17336) or alternatively performing a HEAD request followed by a POST (documented here: https://github.com/fasigpt/appserviceclientcertauth/blob/fa0862dcd44ae570594e21f4bbab4f328cd5eadb/clientcert/Program.cs#L35)
But the only way I've found to reliably eliminate the 503 errors reported by Front Door is by setting the Client Certificates mode to "Ignore" in the App Service settings section in the Azure Portal. This may or may not be suitable for your particular scenario, YMMV - I didn't find this ideal, but for my case it was less bad than intermittent (but also reasonably frequent) 503 errors.
I tried in my local environment and it works fine for me ,Followed by this MS DOC .
Here is my configuration :
Make sure that you have add your custom domain properly which destination as frontend host name.
In backend pool i have tried to set the interval to 5(small value) so the front door knows if backend is down and that it shouldn't routes traffic to that backend anymore
In routing rules, make sure that you have checked all your frontends/domains .
After that you can run by hitting your frontdoor host .
Please refer this Microsoft documentation : Add a custom domain to your Front Door for more information.
Related
After creating Application Gateway Listeners and rules we have uploaded the SSL certificate(HTTPS) for Port:-443, but URL is not hitting.
we are using application gateway WAF , App services, we have configured Listeners, Http setting and rules but still URL is not hitting.
The same configuration is working perfectly on test environment. As the same we have configured on stage environment but this is not working.
Please suggest any setting we missed.
Server id not hitting
As per the error screen shot its TCP_Error meaning its not hitting to SSL layer. Please make sure with the same backend you're able to connect over HTTP listener.
What is outcome of probe. Please make sure to refer probe result
Also I would suggest you to check "diagnose and Solve Problem" of Application gateway.
Working on a project where we are starting to use Deployment Slots in our App Services.
All our Prod apps are located behind Application Gateway, and we would like to also have our Slots located behind Application Gateway.
I understand we can not do this using "App Services" as target type in the Backend Pools as of now, but wondered if it is doable using "IP Address or FQDN" as target type.
I have tried to set it up, with various changes in the "HTTP Settings", Probe and so, but haven´t gotten it up spinning.
Can anyone confirm if this is possible, and have any tips on how this should be configured?
Thanks!
I was able to get this working on one of my slots.
Basically setup the listener with your necessary protocol, port cert, hostname, etc... I'm using multi-site listeners so I can have multiple URLs for the one AppGW/Public IP.
The rule points to the listenter, backend pool and appropriate http setting.
The HTTP setting should be configured to connect to your app service URL accordingly. I'm using the azurewebsite.net URL, so I use well known CA cert & override hostname from backend target:
The backend pool then points to the azurewebsites.net URL:
Make sure that GET / works on your app service and returns 200-399 HTTP status codes. Anything outside that range is a failure and the backend pool will be removed. If you need to create a custom health probe to a URL that will respond properly, or adjust the acceptable HTTP status code (if 401 or 403 due to required auth, then just override it with that for testing purposes for now).
I'm trying to do it again with a second slot and running into 502 errors from the App Gateway... However, I'm also waiting on DNS changes from my network team. My first one with my company domain works via hosts file edit, but the 2nd slot (which has 2 different URLs/listeners configured in the AppGW) doesn't want to work the same way for some reason.
I am trying to use azure frontdoor to access a nginx running in a kubernetes cluster.
I can reach the nginx instance on the public IP, but when trying trough azure front door i get a "The request URI is invalid" error.
The health probes also seem to be failing, even though i did not change any settings and can access nginx via the public IP.
Looking at the time where the backend is availible, i don't see any request to the backend:
I have setup my forwarding rules like this:
EDIT:
It seems that i get a different error message when visiting www.1234h.azurefd.net as opposed to 1234h.azurefd.net (no www).
no www gives a "The request URI is invalid" while the one with www gives "Our services aren't available right now".
I guess this was an issue in azure.
A partial fix was:
wait for a couple of hours
Add a web app to the backend, and change routing rules
After about 10 minutes the http domain started working (still no https)
Changing the forward rule back to kubernetes (with no changes to the backend) gave http access.
I guess the steps are not needed, but the issue was resolved around the same time i did the steps.
If i get https access without changing any settings i will report back to confirm if this were a problem in azure and not with my settings.
Other symptoms that lead me to believe this was an azure issue:
There were a few hours were my connection attemps were not registered in the metrics
After the http magically worked, i see my request at the backend graph mathing the frontend requests
Logging does not work properly (i see "Failed to resolve table or column expression named 'AzureActivity'" even though the column are shown in the tables overview)
EDIT:
Https started working while i wrote this answer.
Again, i did not change anything.
I was getting "The request URI is invalid" only when hitting FD via HTTPS. It worked fine for HTTP.
My FD routing rule was configured as such:
But given that I don't care about HTTP, I just configured my app service to be "HTTPS only" and things started working:
As the title says we are using azure application gateway to front all the traffic to our application. We want the ability to switch it into what will essentially be a maintenance mode and would like to return a 503 as opposed to the standard 502 it returns by default. We have a site Here which simply returns a 503 and the idea would be to switch to a backend pool that contains this site, in the rule. However after setting this up we just get the standard 502 error. Is there a better way to go about this or some step I may be missing?
I have also tried configuring a redirect on the rule however this keeps any part of the url after the fqdn eg: "api.example.me/monitor/this" will turn into "maintenancesite.azurewebsites.net/monitor/this" and as such give a 404 instead
I have an Azure Web app that runs Web API 2 and it provides an access to Azure blobs. I see from logs, that there are some user requests that are denied by the app with code 403 without even getting to the controller itself (there are no corresponding logs). The only special thing about those requests I remarked, is the client IP that has a pattern of 192.168.. I checked the block list of the app and it's empty. Has someone an idea what can be wrong?
Figured it out. When request passes through proxy (some of them maybe), its headers changes (the key case) and the comparison in the code is not working.