Third party reverse proxy with Azure Front Door to an App Service header issues

Question

Third party reverse proxy with Azure Front Door to an App Service header issues

Scot Forsyth 0

I have an existing setup where we have an App Service (contoso.azurewebsites.net) which has multiple custom domains as it is multi-tenanted (clientA.contoso.com, clientB.contoso.com). Some clients are fine with our domain but others reverse proxy (e.g. example.clientB.com reverse proxies to clientB.contoso.com). We use the headers to determine which client and which config/styles to load. This all works fine on either approach for clients.

We are exploring using Front Door for DR and load balancing and it works fine for non-reverse proxy clients however we're facing issues with supporting the reverse proxy clients.

Our client doesn't wish our URL to be accessible directly, only under reverse proxy which they control so we rely on the host header they pass through to detect and limit this (e.g. as per example above we deny direct traffic to clientB.contoso.com if not accompanied by an example.clientB.com host header)

This worked fine on App Services but with Front Door in-between it overwrites all relevant headers and we lose visibility of the reverse proxy host (and therefore the ability to deny direct traffic via our own domain not fed-through our client's reverse proxy)

Is there any mechanism in Front Door to detect/pass through values (even if they have to be written to new headers via rules) originating from the reverse proxy? So far the rules I have tried seem to only have executed after Front Door has already overwritten values coming from the reverse proxy...

To summarise:

(Client owned) Reverse Proxy (abc.com) ----> Azure Front Door (xyz.com) -----> App Service (*.azurewebsites.net)

By the time the code in App Service runs we don't know the request is originally coming from abc.com

Tried setting origin headers, rules, etc but nothing seems to expose it

Scot Forsyth 0 Reputation points

2024-08-02T09:08:52.95+00:00

Hi Kapil,

Thanks for the prompt response. I've attached an image that might help provide visual context.

For the sake of making this easier, please ignore the request to limit access to the App Service (as this will work by default once we've figured out the AFD Header issue).

In the image, I have detailed how the setup worked previously and we have a working implementation this way, followed by how we have set up with AFD.

AFD doesn't appear to be correctly passing the original values in any way for us to determine the client's reverse proxy. In AFD's origin/origin groups I have tried setting a header and leaving it blank but the issue remains

1 answer

Your answer

Scot Forsyth 0 Reputation points

2024-08-02T09:08:52.95+00:00

Hi Kapil,

Thanks for the prompt response. I've attached an image that might help provide visual context.

For the sake of making this easier, please ignore the request to limit access to the App Service (as this will work by default once we've figured out the AFD Header issue).

In the image, I have detailed how the setup worked previously and we have a working implementation this way, followed by how we have set up with AFD.

AFD doesn't appear to be correctly passing the original values in any way for us to determine the client's reverse proxy. In AFD's origin/origin groups I have tried setting a header and leaving it blank but the issue remains

Answer 1

KapilAnanth-MSFT 49,536 Microsoft Employee Moderator

@Scot Forsyth ,

Welcome to the Microsoft Q&A Platform. Thank you for reaching out & I hope you are doing well.

I am afraid I did not get the requirement.

From your verbatim,

You are planning to use 2 reverse proxies (client owned third party and then AFD)
The AppService has custom domains, say, clientA.contoso.com
The third party reverse proxy has example.clientB.com as the domain

Analysis,

If you plan to use AFD, you have to add the custom domain to the AFD
- So AFD's domain would also become clientA.contoso.com (same as AppService's custom domain)
While the above step is not necessary, it is highly recommended
- See why here : Host name Preservation and it's Potential problems
The 3rd party reverse proxy uses a domain, say "abc.com"
- This would try to access the AFD via clientA.contoso.com
- The host header would be "clientA.contoso.com"

Now,

This is what would an ideal setup look like
If my understanding is correct, you want the App Service to be only accessible via the 3rd party reverse proxy' domain - i.e., "abc.com"
Let me know if my understanding is incorrect

Next steps,

Azure Front Door includes headers for an incoming request unless they're removed because of restrictions.
- See : From the Front Door to the backend
So whatever headers sent by the 3rd party reverse proxy is preserved and sent to the backend (App Service)
- You should be able to use the header value in your App Service.
NOTE : AFAIK, the 3rd party reverse proxy would use the host header as "clientA.contoso.com" only
- So, you can use this header to identify where the request came from in your App Service.

Hope this clarifies

Cheers,

Kapil

Scot Forsyth 0 Reputation points

2024-08-02T09:49:57.4133333+00:00

Hi Kapil, thanks for the prompt response.

For ease of understanding the root issue, please disregard the limiting of the app service only to the 3rd party (as this will be solved once I find a fix/workaround for my AFD issue).

I have attached an image that may help better represent the issue and how we utilise the host header to drive behaviour. The top half of the image is how it works currently. The bottom half is what I have been trying to achieve with AFD in front of my App Service but struggling to retain past behaviour.

In the above image, see the host in red is not the same as the host in green, which is what I want to have visibility of in my App Service (as per the amber comments)
KapilAnanth-MSFT 49,536 Reputation points Microsoft Employee Moderator

2024-08-02T09:56:43.7966667+00:00
@Scot Forsyth ,

Did you already set this up and can you actually see the traffic reaching the App Service?

I understand you are not able to identify who the client is, but does the setup work currently? (do customers get a return traffic)

I believe you are using SNI as clientB.contoso.com and host header clientB.com while accessing the AFD

Basically Domain Fronting

Is this correct?

Wrt AFD Configuration

Are you using a single Origin group

Or various Origin groups with the same App Service (for different customers)

The reason I am asking is that if you are using multiple Origin groups , you can

Use the "Origin host header" field for different customers

This way, each client has their own OriginGroup (though the origin is the same App Service) with their own Host Header

Can you configure this and let me know how it goes?
Scot Forsyth 0 Reputation points

2024-08-02T20:10:58.9233333+00:00

Hi Kapil,

Yes the setup with AFD exists and does return traffic.

I also believe we/they are using the domain fronting technique (if we had AFD in place at the time of integration, we would have suggested them adding an additional header declaring their client, however this may not be possible retroactively). Thank you for posting the guidance on that.

I am okay using multiple origin groups and setting individual host headers, I've created a separate Origin Group with my configured Origin to have the client's hostname and assigned it to the Route for my client in my Endpoint - however I've found that if I enter the client's header as per your guidance then the App Service (or could be AFD) returns a 404 to the client because of the mismatch as (from what I can tell) AFD expects the domain to exist in the App Service custom domains (which we can't add because it's the client domain, to my understanding).

Is there a workaround to this? Or have I misconfigured something?

Thank you again for your continued help
KapilAnanth-MSFT 49,536 Reputation points Microsoft Employee Moderator

2024-08-05T08:05:16.73+00:00
@Scot Forsyth ,

Thanks for sharing the info.

The 404 is from App Service.

To understand if the error is from AFD or App Service, you can consider using Access log

From your diagram,

You mentioned the App Service accepts the host header even if it was not added as a custom domain.

Hence I suggested you modify the host header as "clientB.com"

This means, introducing the AFD should not have resulted in the AppService returning a 404 (as this too is sending the same host header as before)

As next steps,

Can you please review your original setup?

Wrt, "AFD expects the domain to exist in the App Service custom domains"

This is not correct

AFD only expects that the health probe (when configured, returns a 200)

Please check the App Service logs for the original setup and AFD Setup and see why the App Service resulted in a 404.

Cheers,

Kapil
Scot Forsyth 0 Reputation points

2024-08-08T08:46:36.85+00:00
Hi Kapil,

We have retained the same structural setup, just put an AFD layer inbetween. I have tried 3 approaches with the origin host header

Put in client host value (clientB.com) - AFD returns a 404 (no evidence of traffic hitting the app service in the logs)

Put in no value - AFD passes through our host value (e.g. clientB.contoso.com) which is unwanted as we'd expect (clientB.com) as per the setup without AFD

Put in any other value:

if the value exists in the custom domains on the app service, it will serve up the app service site

if the value does not exist in the custom domains on the app service, it will 404

I have managed to discuss with clients in the meantime to pass through additional headers as part of the proxy which has allowed me to find a workaround to the problem here and use those instead.

Thanks for your help, but I'll use this as the accepted answer as we've been unable to find a conclusion and we need to have this progressed.
KapilAnanth-MSFT 49,536 Reputation points Microsoft Employee Moderator

2024-08-08T09:06:53.2933333+00:00

@Scot Forsyth ,

I'm glad that you were able to resolve your issue using custom headers and thank you for posting your solution so that others experiencing the same thing can easily reference this!

Ideally, you should be able to see if the response was from Origin or AFD via Access log.

Should you have availability to check the logs/use the above proposed solution and come across an issue, please let me know and we can continue to troubleshoot.

Thanks for your continued contribution on Q&A and appreciate much for taking the time to share your feedback.

Cheers,

Kapil

Please don’t forget to close the thread by clicking "Accept the answer" wherever the information provided helps you, as this can be beneficial to other community members.

Share via

Third party reverse proxy with Azure Front Door to an App Service header issues

1 answer

Your answer