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.


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 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

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.


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 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 (7)

  1. Anonymous says:

    Last week I ran into an issue that was similar in behavior to something that I covered in another previous

  2. euge says:

    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.

  3. AndyOsho says:

    Thank you! Great tip!

  4. CharlieAZ says:

    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.

  5. Dz says:

    Thanks! Probably saved me hours of debugging.

  6. Sina Motamedi says:

    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.

  7. Sina Motamedi says:

    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.

Skip to main content