Azure App Gateway: 502 / SNI/SSL issue? Configuration with App Service

2
votes

I am going a bit nuts here, as I can't get it to work properly.

Environment:

  • App Gateway v2 (WAF)
  • App Service with custom domain
  • End 2 End SSL

Goals:

  • Manage external SSL Certificate on App Gateway only
  • Self-signed SSL on App Service
  • End2End SSL

Setup:

  • BackendPool set to App Service (*.azurewebsites.net)
  • FronendIP configured externally
  • Custom Probe with external Hostname set, Https
  • SSL Listener with FrontendIp/Port(443), host name and external valid certificate
  • Imported the self-signed certificate (cer) into the Trusted Root Authorities in App Gateway (powershell)
  • Http Settings -> Https, Port 443, timeout 30, custom probe, host name set to external address, TrustedRootCertificate assigned (powershell)
  • Basic Rule with SSL listener, Backend pool, Http Setting applied (powershell!)
    • Now this is probably the bit that throws me off, because:
      • Powershell says backend http settings are applied
      • The portal says so too on the "overview" page of the Rule
      • When editing the rule however, the "Http setting" field is empty, and there is a red exclamation mark:

"There are no http settings with pick host name from backend address set. Create a new http setting with pick host name from backend address set and then try again."

However, I don't want this setting, because that would access the back-end as "*.azurewebsites.net", right? I need the backend to be accessed by the external hostname (*.mydomain.com).

Symptoms:

  • Backend health in Portal "Healthy"
  • Accessing the external hostname -> 502 Bad Gateway

I had this working by using "pick host name from backend" and using the azure hostname (*.azurewebsites.net) for internal access, unfortunately our application really needs the external name (and for context: when finished, there will be multiple external names pointing to the same application, and the application changes behavior depending on which hostname is used)

More notes:

  • The App Service is configured with SSL, the self-signed certificate is only assigned to the custom hostname with "SNI"
2
azuresslazure-application-gateway
Do you have an NSG associated with the appgatewaysubnet? If so, do you allow the incoming traffic with port 443 and port 65200 - 65535 for the v2 SKU, see here – Nancy Xiong
No, there is no NSG associated. And while using "pick host name from backend", the end2end connectivity does work (but the SNI hostname is not passed), so it's not a network issue. – MichelZ
AND the Probe works OK, too. – MichelZ
What is the specific error on your side? – Nancy Xiong
Site: 502 Bad Gateway - nginx/1.13.8 Backend Health: Healthy – MichelZ

2 Answers

1
votes

This turns out to be a side-effect of "V2" being in "Preview" (as of 2018-12-13). The "Preview" label is not immediately apparent. The Azure Portal does not mention anything about it being in Preview, and all the Documentation talks about "Autoscaling" being in Preview.

Turns out, "V2" is meant with the "Autoscaling" feature, so the whole "V2" thing is in Preview.

We have re-done the exact same setup with the "V1" app gateway type, and it works as expected.

I wish they would clearly label preview things in the Portal, too...

0
votes

When editing the rule however, the "Http setting" field is empty, and there is a red exclamation mark:

Similar scenario in Github here. It seems WAF_v2 won't accept .cer files when setting HTTPS Settings. When you whitelist the CER cert with Http settings using PowerShell, it is not reflected in the portal. A possible reason is that application Gateway does not support Authentication Certificates for the WAF_v2 tier. You can read the known-issues-and-limitations in Application Gateway with WAF_v2 and End to end SSL with the v2 SKU.

If the certificate is self-signed, or signed by unknown intermediaries, then to enable end to end SSL in v2 SKU a trusted root certificate must be defined. Application Gateway will only communicate with backends whose Server certificate’s root certificate matches one of the list of trusted root certificates in the backend http setting associated with the pool.

In addition to root certificate match, Application Gateway also validates if the Host setting specified in the backend http setting matches that of the common name (CN) presented by the backend server’s SSL certificate. When trying to establish an SSL connection to the backend, Application Gateway sets the Server Name Indication (SNI) extension to the Host specified in the backend http setting.

If pick hostname from backend address is chosen instead of the Host field in the backend http setting, then the SNI header is always set to the backend pool FQDN and the CN on the backend server SSL certificate must match its FQDN. Backend pool members with IPs are not supported in this scenario.

About the 502 Bad Gateway error, the backend health is healthy on your side. If there is not a firewall blocking request or response from your backends, I may suggest checking the error on your web server side and make sure the backend is responding to the request sent by Application gateway within 30 seconds(Default value).

You could get more references from troubleshooting steps and diagnostic logs, and metrics for Application Gateway and here.

Hope this will help.