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:
Related
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.
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'm migrating a complete infrastructure over to Azure; it's been slow going as there's so much to learn and for every two steps forward, there seems to be one step back.
After what seems like an eternity, I think I've got it all sorted with one exception.
The architecture is as follows:
Azure Traffic Manager ==> 2 Azure Application Gateways (geo separated) ==> Azure App Service
A custom domain is used for the traffic manager and the gateways are listening for the same domain and, when the route matches, passing on the requests down to the app service.
The actual app itself is a ASP.NET MVC application and it uses forms authentication; and this is where the challenge happens.
When navigating to the public address: client.domain.com and hitting the website, it determines that the user is not authenticated and sends the browser to the login page... so far so good but, rather than using client.domain.com/login it uses the web-server dns name, so client.azurewebsites.com/login
How do I go about changing the behaviour so that it uses the external DNS name rather than the website name?
I can't setup custom domains on the app service as the only route into the site is via the gateway as this is also the firewall.
Is there some Web Config setting I can make? I'm looking at the outbound rewrite rules but these seem to only work on tags rather than 302 redirects.
Any thoughts would be most welcome.
You need to setup custom dns names on your webapp (you can use TXT record to verify dns name, so i dont see a reason why you can add it to the webapp). or you can alter the code.
In order to solve this problem, I had to make a code change to the web app itself. Not ideal but it worked.
What I had to do was to extend the code that redirects an unauthenticated request to the login page by sniffing for the X-Original-Host HTTP Header that the App Gateway forwards on. This contains the public facing DNS name. If the header is present and it is on a pre-approved white-list (so as to prevent any hijacking), then redirect the user to the login page for this domain, rather than the one the server is listening on directly (so use client.domain.com rather than client.azurewebsites.com)
I have setup an Azure WAF, via the Azure Portal, to point to an App Service which has a custom domain. The App Service has 2 domain names:
mysite.azurewebsites.com
subdomain.mysite.com
When I select "Pick Hostname from backend address" for the Probe and the Backend HTTP Settings, the Custom domain is picked up. I am also using SSL and this is working. However weirdly when I get past my login page on the app, the Application Gatewoy/WAF seems to resort to using the mysite.azurewebsites.net url. I tried following the recommendation in the following link, but it does not work for me.
Azure WAF infront of Web App changes HostName
Ie I deselected "Pick Hostname from backend address" and put "subdomain.mysite.com" as the hostname. This works for the probe, but when I specifiy this for the hostname in HTTP Settings, I get "Update Failed" without any explanation.
Any thoughts please?
Thanks.
EDIT: If I change the CNAME to bypass the WAF and go direct to the App Service, it works fine.
EDIT2: This may be relevant. The URL gets rewritten post authentication. There are a few links on the login page and these have the correct custom domain in them. However once the user logs in, the app links gets rewritten to use *.azurewebsites.net as the suffix.
EDIT3: Another thought... Is the "Probe" path wrong? I am currently using "/"
From MS docs....
Path / or another path
The remainder of the full url for the custom probe. A valid path starts with
'/'. For the default path of http://contoso.com just use '/'
Just spoke with MS. You need to use the "FQDN" in the backendpool and not the "AppService" option.
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.