Error While Configuring WAP–The Underlying Connection Was Closed

 

We have seen a couple of these issues this week when running the Web Application Proxy wizard to complete an install. I am pretty sure we will see quite a few more of these so I thought I would write up a quick blog on the issue.

Problem

After installing the role for Web Application Proxy you are trying to finish the configuration wizard but you encounter the below error.

“An error occurred when attempting to establish a trust relationship with the federation service. Error: The underlying connection was closed: An unexpected error occurred on a send.”

Figure 1 shows the error we see in the wizard.

Fig. 1

Data Gathering and Analysis

It was not immediately obvious what was causing this error so the first place I looked for more information was in the Event Viewer. Under the ADFS Admin events you may find an Event ID 393.  The details do not tell us much more than the error in the wizard.

Fig. 2

I wanted to see what was happening on the wire so I set up Netmon 3.4 to capture the network trace and filtered it to see the traffic destined for the IP address of the ADFS Server. In this case it was 10.0.0.5. You would also want to take a trace from the ADFS server to make sure that the traffic is truly making it there.

We can see in Figure 3 that right after the Client Hello in the trace, the ADFS Server resets the connection.

Fig. 3

Drilling down into the Client Hello packet we find an extension called “Server Name”

Fig. 4

As we can see the server name is fs.fabrikam.com

The server name in the trace was what was put in the WAP configuration wizard during the second step (Figure 5).

 

Fig. 5

We should compare this to the bindings in ADFS. From an administrative command prompt on the ADFS Server run the command netsh http show ssl

Figure 6 shows the results of the netsh command.

Fig. 6

As we can see the bindings to port 443 do not match what was in the Server Name of the network trace.

Resolution

When planning your ADFS infrastructure always keep in mind what you want your external users to use as the FQDN. In this case the FQDN that was intended did not actually match the Federation Service name. I was able to easily remedy this by uninstalling the ADFS role and then reconfiguring it using the intended external FQDN as the Federation Service name. In the example above I would reconfigure it as fs.fabrikam.com. The Web Application configuration wizard will then complete successfully.

Note: If the information contained here was useful please let me know in the comments below. Also, if there are any corrections needed or you would like to see future content on a particular subject please let me know that as well. Thanks!

Comments

• Anonymous
  June 22, 2015
  Last week I ran into an issue that was similar in behavior to something that I covered in another previous
• Anonymous
  August 12, 2015
  Thanks, "netsh http show ssl" helped me identify the problem. I hoped, actually, that things are not that bad, that I'll have to reinstall the role completely, but it looked like it was the only option. Mind also, to clean up your AD from previous installation by LDP or ADSIedit.
• Anonymous
  September 01, 2015
  Thank you! Great tip!
• Anonymous
  September 03, 2015
  Find the incorrect hostname binding in the registry, replace it with the correct hostname, reboot ADFS server. WAP server connects successfully after this, in my experience. Thus no need to reinstall ADFS. If your Federation Service properties show the certs for ADFS using the old name, ensure that you configure the service to use the right name, then in PowerShell do "Update-AdfsCertificate –Urgent" to cause reissuance of the ADFS certs with the right name. Reboot server.
• Anonymous
  October 19, 2015
  Thanks! Probably saved me hours of debugging.
• Anonymous
  March 31, 2016
  I'm getting the exact same error and event ID. However, my ADFS servers show the correct binding when I run netsh http show ssl. We planned for that part correctly yet we are encountering this error...not sure exactly what the problem is yet but will try to post my solution when I get it figured it out.
• Anonymous
  March 31, 2016
  My problem was with our F5 load balancer. We were load balancing/proxying our ADFS farm using F5 and I was using an 'http' profile. I thought my config was working because the sign on page was loading via the F5 and the XML files as well. But as soon as I removed the 'http' profile, the ADFS proxy was able to successfully authenticate to the ADFS farm and complete its configuration.
  • Anonymous
    March 30, 2017
    Hello Sina Motamedi, We have a similar setup, at first I couldnt get the proxies to connect, but once I removed the http profile I was able to successfully create the cluster. I had the two internal adfs servers in a pool and with a custom script I got from the F5 page and all worked with Active Monitors, but now that I setup the external adfs wap, my internal ones dont work. Is your config for both internal and external the same or are they different?
• Anonymous
  April 16, 2017
  I believe there was no need to remove and reinstall ADFS role. you could try this netsh command: netsh http delete hostnameport=x.x.x.x:x.x.x.xThanks
• Anonymous
  June 12, 2017
  You are a Star! I have spent 3 hours without joy.. this solved my issue..
• Anonymous
  October 01, 2017
  The comment has been removed
  • Anonymous
    November 14, 2017
    Is your time settings in your WAP machines is not match your ADFS servers ? This is may lead to break the trust between WAP and ADFS . Also can both WAP servers telnet to the 443 port of ADFS servers ?