Recently I was called in to help configure Azure Front Door for a client who is upgrading from Sitecore 10 to 10.4 running on Azure Kubernetes Services (AKS). As a team we ran into some roadblocks along the way, but finally got it configured for us to begin internal testing. I thought it might be useful for someone in the future who could possibly get stuck on a similar task (or most likely myself totally forgetting what I have done), so I created this post.

The Configuration Task

The environment that we were migrating from utilized Front Door classic and Sitecore 10 with Traefik as the ingress controller. Front Door handled all of the HTTPS externally, as well as regular routing tasks.

The new implementation of Sitecore 10.4 on Kubernetes is slightly different than what existed for version 10. Mainly, ingress was handled by Nginx in 10.4. With the new implementation, testing had been done with direct access to the ingress controller. My task was to implement Front Door to add all of the capabilities that come with that product. The existing internal communication in the cluster was TLS using self signed certs. Once we had communication working correctly, we needed to implement any routing rules as well as add the WAF policies. This seemed like an easy enough task, mainly copying in the configurations from the legacy and adapting to Front Door Standard. Or so I thought…

Roadblocks

Initially, we ran into issues with connectivity to the controller period. The error we received was OriginTimeout from Front Door.

The second error we kept encountering was an OriginCertificateSelfSigned error. This was due to the self signed certs within the cluster being used by nginx for communication.

To verify that it was an issue with Front Door, we set the host names locally to the ingress controller, and were able to access the content.

Updating the Route

First, we made sure that the route was configured correctly. In Azure Front Door Standard, this is under Settings on the left hand side. Selecte Setttings > Front Door manager and then edit the route by selecting the three buttons. Once there, we ensured our domains have been selected and were forwarding to HTTP. In our set up Front Door handles the TLS traffic, so we set up HTTP to redirect to HTTPS in the route as well.

Configuring the Origin Groups

When the route was configured correctly, we moved on to the Origin Group configuration. This is located in the same Settings section. Under Settings > Origin groups, select the origin group to edit. Once the panel opens up, either add an origin, or edit the existing origin. Next select an origin type of Custom and set the Host name to the IP address of the ingress controller. Then, add the host name of the CD instance we are trying to access to the Origin host header. Once that is saved, ensure all other settings are up to date for the origin group, or update additional origins. Clicking update takes a while to apply. Once applied, there was one more step. (Visuals for these steps are below)

Lastly, we needed to make sure that the ingress controller was forwarding the correct information. we updated the Config map for the ingress controller to include use-forwarded-headers in the data section. Once complete, verify that traffic is correctly reaching the instance by accessing the site in a browser

data:
  use-forwarded-headers: 'true'

Conclusion

Although it appeared to be a simple fix, the numerous configuration options can quickly make it a complex challenge. Setting the correct configurations promptly helps save valuable troubleshooting time.