FrontDoor URL for Private Link do not work on setting HTTP_X-Forwarded-Host in HTTP_HOST header

Question

FrontDoor URL for Private Link do not work on setting HTTP_X-Forwarded-Host in HTTP_HOST header

Alok Kumar 0

We have created an endpoint on Azure Front Door to access .azurewebsites.net through private link, and in my app service's web config I have created below rewrite rule to set HTTP_HOST value same as HTTP_X-Forwarded-Host. After adding this rule my Front door URL stops working. However as soon I remove this rule, front door url starts working. Issue is with Private link only. As soon as I route from public network, rewrite rule works as expected. Can you please suggest?

Ben Gimblett 4,560 Reputation points Microsoft Employee

2023-05-16T14:49:31.18+00:00

Hi Alok - thanks for the question.

Are you using a custom domain on front door? So something like

GET Contoso.com => Azure Front Door => contoso.azurewebsites.net

In that example the client requests a page from Contoso.com, and public DNS resolves this to your front door which then itself connects to web apps via the azurewebsites.net default name

The way private link works for app service is this:
If you set a custom host name against the web app then it CNAMEs (recommended) the custom name points to the default name

tailspin.com => tailspin.azurewebsites.net

When you set up a private link and using that same example the custom name resolves to the default name which resolves to the private link:

tailspin.com => tailspin.azurewebsites.net => tailspin.privatelink.azurewebsites.net

(For some more detail see here)

It means that with a private link the web app default name must be used for all requests, or the same must be resolvable from a custom name.

The x-forwarded-host header from Az Front door would contain the host name the client originally requested.

If you could provide some more detail here that would be great (assuming someone else is not able to answer based on the info already provided :))
Alok Kumar 0 Reputation points

2023-05-17T05:02:25.54+00:00

Hi @Ben Gimblett

Let me try to add more details here. Currently my environment is a non prod environment so I don't have a custom domain yet.

I have an endpoint like myapplicationname.azurefd.net and I am this endpoint to access my site

In origin groups I have an origin defined for myappservice.azurewebsites.net which is an MVC application. For this origin I have selected the checkbox to enable private link service.

In web.config file of myappservice.azurewebsites.net I have created a rewrite URL which sets HTTP_HOST server variable to the value received in HTTP_X-Forwarded-Host. As soon as I add this rewrite rule in web.config myapplicationname.azurefd.net stops working. On removing this rule, it starts working again.

Same set up works in my other non prod environment perfectly fine, only difference is that in this other environment we have not enabled the private link service.

Thanks
Ben Gimblett 4,560 Reputation points Microsoft Employee

2023-05-17T15:52:03.5833333+00:00

hey Alok - if i try and repro this quick with a Windows WEB App (S1) set to dot net 4.8 and deploy a basic MVC project (from the started template) and copy your rewrite rule in under system.webServer => rules

Then if I test with Postman it works (just the myapp.azurewebsites.net) and if I test with the inclusion of an "X-Forwarded-Host" header (that AFD would add) then it doesnt work - I get a 500 from the rewrite module

What is the requirement the rule is fulfilling here?

I am not an IIS expert - but I am unsure the rewrite module would allow the host header to be rewritten - it only makes sense if the host is acting as a reverse proxy (so in IIS terms with ARR added)
Alok Kumar 0 Reputation points

2023-05-18T05:08:55.1766667+00:00

Hi @Ben Gimblett

If your azurewebsites URL is giving 500 error after adding rewrite rule that is because your azure app is not able to resolve domain you are passing in "X-Forwarded-Host". In my case my app service resolves both URLs. You might need to add an additional binding in your app service so that it resolves for the host passed in "X-Forwarded-Host" also and after that you add rewrite rule and try to access the site with the front door URL. In this scenario your azurewebsite url will work but FrontDoor URL will not work.

My application is a Sitecore CMS based application and is multisite implementation. Sitecore resolves the site on the basis of HTTP_HOST and that is the reason I am trying to rewrite this value. My requirement is kind of related to this article for your reference

https://georgechang.io/posts/2020/sitecore-multisite-support-with-azure-application-gateway-and-app-services/

As I mentioned I am getting issue only if Private Link Service is enabled in origin. If I remove it, it works fine. I am not sure why routing from Microsoft private network will not allowing the rewriting of the header but works for routing via public network.

Thanks
Ben Gimblett 4,560 Reputation points Microsoft Employee

2023-05-18T09:23:16.42+00:00

Hey Alok - OK
I see the point here - you want a kind of "pseudo" SSL termination at front door with multiple custom domains all going to the web app default domain, but then to remap the host before ASP net request processing so that sitecore can resolve the correct site context based on the original host header

So quickly reading the link you supplied (thankyou) I realise I was missing the step to enable the server variable
Once I added the xdt transform this fixed my 500 error

Note: The URL rewrite module doesn't appear to validate the host you're re-writing and it doesn't appear to need to be a binding on the web app (which in any case would more or less defeat the point of what you're trying to achieve which is keep the multiple domains config at front door)

In any case it works for me, although I must be clear and say I am NOT using a custom name

So i can use any http client

(client) https://[myfrontdoor].azurefd.net/ => (private link) https://[mywebapp].azurewebsites.net

If i change the index page of my default dot net 4.8 MVC app to output the "Context.Request.Url" value then, if I call through AFD (or through postman with a x forward host header) I see the original client URL for that value (the value rewritten from the x forward host header), and if I call the web app direct then I see the web app URL echo back.

Again this is configured with private link between Front door premium and my web app

You did indicate this broke for you without adding the custom name binding to Az front door , is that correct? Can you confirm if the problem only exists once you add the custom name at Az Front door and if you did any further config with the web app (such as add a custom name binding there too) ?
Ben Gimblett 4,560 Reputation points Microsoft Employee

2023-05-18T09:29:12.4066667+00:00

I would also add that from the outside in (Web apps architecture is that a reverse proxy will send on the client request to your worker vm running your website) I can see no evidence of the rewrite causing any side effect
the response headers are consistent (no change to cache headers for example) and there's no redirect. This is consistent with the rule being "inbound" not "outbound"
Alok Kumar 0 Reputation points

2023-05-18T10:07:51.21+00:00

Hi @Ben Gimblett

You are right that we want to add multiple custom domains on Front Door and at app level we want to set HTTP_HOST server variable depending on the what custom domain request is coming from.

Currently I am also testing below scenario

https://[myfrontdoor].azurefd.net/ => (private link) https://[mywebapp].azurewebsites.net

But for me whenever I am adding that rewrite rule then https://[myfrontdoor].azurefd.net/ stops working.

However rewrite rule works for me in below scenario.

https://[myfrontdoor].azurefd.net/ => (without private link) https://[mywebapp].azurewebsites.net

So I am not sure what to check for the issue.

Thanks

1 answer

Your answer

Ben Gimblett 4,560 Reputation points Microsoft Employee

2023-05-16T14:49:31.18+00:00

Hi Alok - thanks for the question.

Are you using a custom domain on front door? So something like

GET Contoso.com => Azure Front Door => contoso.azurewebsites.net

In that example the client requests a page from Contoso.com, and public DNS resolves this to your front door which then itself connects to web apps via the azurewebsites.net default name

The way private link works for app service is this:
If you set a custom host name against the web app then it CNAMEs (recommended) the custom name points to the default name

tailspin.com => tailspin.azurewebsites.net

When you set up a private link and using that same example the custom name resolves to the default name which resolves to the private link:

tailspin.com => tailspin.azurewebsites.net => tailspin.privatelink.azurewebsites.net

(For some more detail see here)

It means that with a private link the web app default name must be used for all requests, or the same must be resolvable from a custom name.

The x-forwarded-host header from Az Front door would contain the host name the client originally requested.

If you could provide some more detail here that would be great (assuming someone else is not able to answer based on the info already provided :))
Alok Kumar 0 Reputation points

2023-05-17T05:02:25.54+00:00

Hi @Ben Gimblett

Let me try to add more details here. Currently my environment is a non prod environment so I don't have a custom domain yet.

I have an endpoint like myapplicationname.azurefd.net and I am this endpoint to access my site

In origin groups I have an origin defined for myappservice.azurewebsites.net which is an MVC application. For this origin I have selected the checkbox to enable private link service.

In web.config file of myappservice.azurewebsites.net I have created a rewrite URL which sets HTTP_HOST server variable to the value received in HTTP_X-Forwarded-Host. As soon as I add this rewrite rule in web.config myapplicationname.azurefd.net stops working. On removing this rule, it starts working again.

Same set up works in my other non prod environment perfectly fine, only difference is that in this other environment we have not enabled the private link service.

Thanks
Ben Gimblett 4,560 Reputation points Microsoft Employee

2023-05-17T15:52:03.5833333+00:00

hey Alok - if i try and repro this quick with a Windows WEB App (S1) set to dot net 4.8 and deploy a basic MVC project (from the started template) and copy your rewrite rule in under system.webServer => rules

Then if I test with Postman it works (just the myapp.azurewebsites.net) and if I test with the inclusion of an "X-Forwarded-Host" header (that AFD would add) then it doesnt work - I get a 500 from the rewrite module

What is the requirement the rule is fulfilling here?

I am not an IIS expert - but I am unsure the rewrite module would allow the host header to be rewritten - it only makes sense if the host is acting as a reverse proxy (so in IIS terms with ARR added)
Alok Kumar 0 Reputation points

2023-05-18T05:08:55.1766667+00:00

Hi @Ben Gimblett

If your azurewebsites URL is giving 500 error after adding rewrite rule that is because your azure app is not able to resolve domain you are passing in "X-Forwarded-Host". In my case my app service resolves both URLs. You might need to add an additional binding in your app service so that it resolves for the host passed in "X-Forwarded-Host" also and after that you add rewrite rule and try to access the site with the front door URL. In this scenario your azurewebsite url will work but FrontDoor URL will not work.

My application is a Sitecore CMS based application and is multisite implementation. Sitecore resolves the site on the basis of HTTP_HOST and that is the reason I am trying to rewrite this value. My requirement is kind of related to this article for your reference

https://georgechang.io/posts/2020/sitecore-multisite-support-with-azure-application-gateway-and-app-services/

As I mentioned I am getting issue only if Private Link Service is enabled in origin. If I remove it, it works fine. I am not sure why routing from Microsoft private network will not allowing the rewriting of the header but works for routing via public network.

Thanks
Ben Gimblett 4,560 Reputation points Microsoft Employee

2023-05-18T09:23:16.42+00:00

Hey Alok - OK
I see the point here - you want a kind of "pseudo" SSL termination at front door with multiple custom domains all going to the web app default domain, but then to remap the host before ASP net request processing so that sitecore can resolve the correct site context based on the original host header

So quickly reading the link you supplied (thankyou) I realise I was missing the step to enable the server variable
Once I added the xdt transform this fixed my 500 error

Note: The URL rewrite module doesn't appear to validate the host you're re-writing and it doesn't appear to need to be a binding on the web app (which in any case would more or less defeat the point of what you're trying to achieve which is keep the multiple domains config at front door)

In any case it works for me, although I must be clear and say I am NOT using a custom name

So i can use any http client

(client) https://[myfrontdoor].azurefd.net/ => (private link) https://[mywebapp].azurewebsites.net

If i change the index page of my default dot net 4.8 MVC app to output the "Context.Request.Url" value then, if I call through AFD (or through postman with a x forward host header) I see the original client URL for that value (the value rewritten from the x forward host header), and if I call the web app direct then I see the web app URL echo back.

Again this is configured with private link between Front door premium and my web app

You did indicate this broke for you without adding the custom name binding to Az front door , is that correct? Can you confirm if the problem only exists once you add the custom name at Az Front door and if you did any further config with the web app (such as add a custom name binding there too) ?
Ben Gimblett 4,560 Reputation points Microsoft Employee

2023-05-18T09:29:12.4066667+00:00

I would also add that from the outside in (Web apps architecture is that a reverse proxy will send on the client request to your worker vm running your website) I can see no evidence of the rewrite causing any side effect
the response headers are consistent (no change to cache headers for example) and there's no redirect. This is consistent with the rule being "inbound" not "outbound"
Alok Kumar 0 Reputation points

2023-05-18T10:07:51.21+00:00

Hi @Ben Gimblett

You are right that we want to add multiple custom domains on Front Door and at app level we want to set HTTP_HOST server variable depending on the what custom domain request is coming from.

Currently I am also testing below scenario

https://[myfrontdoor].azurefd.net/ => (private link) https://[mywebapp].azurewebsites.net

But for me whenever I am adding that rewrite rule then https://[myfrontdoor].azurefd.net/ stops working.

However rewrite rule works for me in below scenario.

https://[myfrontdoor].azurefd.net/ => (without private link) https://[mywebapp].azurewebsites.net

So I am not sure what to check for the issue.

Thanks

Answer 1

Ben Gimblett 4,560 Microsoft Employee

Hi Alok - it might be worth trying again with a new resource group, new AFD premium and new web app with just a basic MVC app from visual studio template (you can of course remove these resources after) to get you into a "known" state

In my example I used

Az Web App (S1) on Windows and Net4.8
Az Front Door premium - the only config was to add the web app as an origin and select to use private link
New ASP NET MVC app in Visual Studio , right click publish to the web app (as this is a test and that's OK!)

I tested following
(1) Published The MVC code to the web app and tested it responds once published (GET on the index)
(2) I checked the same page is now accessible via my front door premium profile
(3) Applied the xdt on the web app as per blog post
(4) modified my web config by adding the rewrite rule and re-published)
(5) tested again direct on the web app, to the web app with postman (manually adding the x forward host header) and finally through front door

As mentioned before i added a line in the index view to output the Context.Request.Url as a visual aid to the host value being re-written correctly.

Ben Gimblett 4,560 Reputation points Microsoft Employee

2023-05-18T11:39:50.2666667+00:00

As per previous - if the host header is there and the rewrite is working - then i see no reason for this to interfere with the private link that is deployed for front door. Reason being; in the end the rewrite rule is just modifying the request context once the host (win/IIS) has received it , but before the ASP NET code runs

All the comms between front door, the web app front end role and the web app worker host is established and the request stream is buffered and available on the web host at this point awaiting the response

There is no reason for the rewrite which is just in context of the asp net code now, to impact upstream

That being said a real application may be more complex if that modified host value is being used then in some way else by the application code and that is causing some side effect (sitecore is a very complex application) but for a simple use case, a simple GET request/response, it seems to work fine. The simple use case is a good place to start though because it proves the comms and that the rewrite rule does not impact the end to end request/response for simple HTTP request

Share via

FrontDoor URL for Private Link do not work on setting HTTP_X-Forwarded-Host in HTTP_HOST header

1 answer

Your answer