Azure Private load balancer to Https web sites

Hello Rajesh,

Check the following:

1. Check the IIS bindings for each site. Make sure that each site is bound to the correct IP address and port. If the bindings are incorrect, you may need to update them to match the load balancer settings. To check the load balancing rule, go to the Azure Load Balancer resource that is being used and navigate to the "Load balancing rules" section. Here, you can view and modify the rule settings. You can check the following:

   a) Remote Desktop into each web server that hosts the web sites you want to check.
   
   b) Open the "Internet Information Services (IIS) Manager" by typing "inetmgr" in the Windows Start menu search box.
   
   c) In the IIS Manager window, navigate to the "Sites" node in the left-hand pane.
   
   d) Select the site you want to check and then click on the "Bindings" option in the right-hand pane.
   
   e) In the "Site Bindings" window, check that the protocol is set to "https", the IP address is set to the correct IP address of the web server, and the port is set to "443".
   
   f) Repeat this process for each site hosted on the web server.
   
   g) Once you have confirmed the correct bindings, compare them with the load balancing rule in the Azure Load Balancer resource.
   
   h) To view the load balancing rule, navigate to the Azure Load Balancer resource being used and then click on the "Load balancing rules" section.
   
   i) Check that the rule is set to use "TCP" protocol, the front-end IP address matches the internal IP address of the load balancer, and the front-end port is set to "443".
   
   j) Check that the back-end pool contains the correct web servers and that the back-end port is set to "443".
   
   k) If the bindings do not match the load balancing rule, you may need to update them to ensure that the requests are sent to the correct back-end pool and web server.
   
   l) Once you have made the necessary updates, save the changes and test the websites to confirm that they are now accessible through the load balancer.
   

   2. Check the SSL certificate bindings for each site. Ensure that the certificate is bound to the correct site and that the certificate hash matches the thumbprint of the SSL certificate installed on the web server. To check the health probe settings, navigate to the "Health probes" section under the Azure Load Balancer resource. Here, you can view and modify the probe settings. You can check the following:
      1. Remote Desktop into each web server that hosts the web sites you want to check.
      2. Open the "Internet Information Services (IIS) Manager" by typing "inetmgr" in the Windows Start menu search box.
      3. In the IIS Manager window, navigate to the "Sites" node in the left-hand pane.
      4. Select the site you want to check and then click on the "Bindings" option in the right-hand pane.
      5. In the "Site Bindings" window, select the "https" binding and then click the "Edit" button.
      6. In the "Edit Site Binding" window, select the appropriate SSL certificate from the "SSL certificate" dropdown list.
      7. Verify that the certificate is bound to the correct site by checking the "Host name" field.
      8. Check that the certificate hash matches the thumbprint of the SSL certificate installed on the web server by running the following command in the Windows PowerShell console:
      Get-ChildItem -Path cert:\LocalMachine\My This will display a list of all certificates installed on the web server. Look for the certificate that is bound to the site and then verify that the "Thumbprint" field matches the hash in the "Edit Site Binding" window.
      9. Repeat this process for each site hosted on the web server.
      10. Once you have confirmed the correct certificate bindings, test the websites to confirm that they are accessible through the load balancer.
      11. To check the health probe settings for the Azure Load Balancer, navigate to the Azure Load Balancer resource and then click on the "Health probes" section.
      12. Check that the probe is set to use "HTTPS" protocol, the probe port is set to "443", and the probe path matches the path to the root of the site.
      13. If necessary, you can modify the probe settings to better match the requirements of your web application.
      14. Once you have made the necessary updates, save the changes and test the websites to confirm that they are now accessible through the load balancer.
   3. Check the HTTP and HTTPS traffic logs on the web servers. This will help you determine if the requests are reaching the web server and what response the server is sending back. To check the NSG settings, navigate to the network security group that is associated with the web servers and view the inbound security rules. Ensure that there is a rule allowing inbound traffic on port 443.
   4. Use network tracing tools like Wireshark or Network Monitor to capture network traffic between the load balancer and web servers. This will help you determine if the load balancer is sending the requests to the correct backend pool and if the web servers are responding. To check the event logs on the web servers, you can use the Azure Diagnostics Extension or Azure Monitor to collect and analyze log data. You can also access the event logs directly on the web servers.
   5. Check the firewall logs on the web servers to see if any traffic is being blocked. This may help you determine if there is a firewall rule that is blocking the traffic. To check the HTTP and HTTPS traffic logs on the web servers, you can use IIS logs or other web server logging tools to capture and analyze traffic.
   6. Try accessing the sites using the IP addresses of the web servers instead of the custom domain names. This will help you determine if the issue is related to the DNS or the load balancer. To use network tracing tools like Wireshark or Network Monitor, you may need to deploy these tools on the web servers or use a separate virtual machine to capture network traffic between the load balancer and web servers.
   7. Check the system and application event logs on the web servers for any errors related to IIS or the web applications. To access the system and application event logs on the web servers, you can use the Event Viewer tool within the Windows operating system. Check how can you do that: a) Remote Desktop into the web server that you want to check. b) Open the "Event Viewer" tool by typing "eventvwr" in the Windows Start menu search box. c) In the "Event Viewer" window, navigate to "Windows Logs" and then "System" or "Application" depending on which logs you want to view. d) Look for any errors or warnings related to IIS, the web applications, or SSL certificates. You can filter the logs by specific event types, event IDs, or time range. e) If you find any errors or warnings, investigate them further to determine the cause of the issue. You can double-click on an event to view more details and possible solutions. f) If necessary, you can export the event logs to a file for further analysis or to share with others.

Keep in mind that the Event Viewer logs can get quite large, so you may want to clear or archive older logs periodically to avoid running out of disk space. Also, note that certain events may be logged in other categories or logs, so you may need to explore other sections of the Event Viewer tool to find all relevant events.

Hope I help

@Rajesh Ambakkat

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

I understand that you would like to host your webservers behind an ILB.

I see that you have mentioned that the backend is unhealthy as the probes are failing.

Firstly, you must make sure the health probes are up, only then the ILB will route traffic to the backend.

Per our discussion, your configuration is as follows,

• Both the webservers are capable of handling requests to https://application1.abc.net as well as https://application2.abc.net
• You have a single backend pool and this pool contains these two webservers
• You have a single TCP 443 rule in your Azure ILB to send traffic to the backend pool.

Wrt the backend health,

• You were using a HTTP/HTTPS probe.
• I suggested you to use TCP and check if the probes succeed.
• You confirmed this resolved the issue and the websites are accessible

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.