Question

I am porting a .NET application that works in .NET 3.5+ to WinRT, and it includes a WCF service client (created using ChannelFactory<T> programmatically) that shares almost all its code (i.e. as much as I could make identical) with the original version of the program. The service is accessed via SSL on port 9443 and uses Windows authentication. The original version of the code works flawlessly, but the WinRT port normally fails with a triple-decker sandwich of exceptions: I get an EndpointNotFoundException (“There was no endpoint listening at https://…”) with an inner exception of WebException (“Unable to connect to the remote server”) with an inner exception of SocketException (“An attempt was made to access a socket in a way forbidden by its access permissions 192.168.x.x:9443”).

The odd thing is, this will fail consistently UNLESS I have Fiddler acting as a proxy and capturing traffic.

Now, more details.

• The SSL cert is valid, from a trusted authority, and covers the Host Header Name attached to my IIS site (and only that name).
• I can browse to the .svc file and its ?wsdl without getting any errors, and the wsdl itself reports the exact URL I use from my application.
• The site in question has bindings for https on 9443 and http on 9999 (both have the host header name associated with them)

• I have the following clientaccesspolicy.xml in the site root, and it is accessible via both http and https via the appropriate ports:

  <?xml version="1.0" encoding="utf-8"?>
  <access-policy>
    <cross-domain-access>
      <policy>
        <allow-from http-request-headers="*">
          <domain uri="*" />
        </allow-from>
        <grant-to>
          <resource path="/" include-subpaths="true"/>
        </grant-to>
      </policy>
    </cross-domain-access>
  </access-policy>
  

• The service account running the service has a UPN associated with it, since someone suggested that might help. I tried putting this into <servicePrincipalName/> in my endpoint’s <identity />, but to no avail; using <dns /> there didn’t help, either.

• The binding is BasicHttpBinding with BasicHttpSecurityMode.Transport, and I am setting ClientCredentialType = HttpClientCredentialType.Windows. The credentials are currently hardcoded and are correct. But I don’t think any of this is the problem, because…
• I can set up the service call in a loop and watch it fail, and fail, and fail, and fail, until I Alt+Tab over to Fiddler and start capturing traffic. This redirects the service call through Fiddler’s local proxy, I understand, and for whatever reason this makes it just work perfectly– I don’t even need to restart the program, let alone recompile it.
• This is the same whether I have installed Fiddler’s man-in-the-middle certs as trusted or not, whether I choose to decode SSL sessions or not.
• The traffic I see when I do this with Fiddler is not particularly illuminating to me; looks like a standard Negotiate handshake with an HTTP 401 error followed by a successful connection thereafter.
• IIS is version 7. The logs (in inetpub\logs) do not seem to show anything interesting– in fact, I never seem to see anything there unless Fiddler is attached, when everything works normally.
• I tried to use Wireshark to sniff this out, but the results are basically useless to me. It doesn’t even look like Wireshark picks anything up until I start capturing in Fiddler, and then I get traffic, but I don’t know enough to know if I’m just looking at it wrong.
• Trying to add a standard Visual Studio proxy using Add Service Reference results in the exact same behavior as my custom code.
• Just for kicks, to see if WinRT had an unpublished limitation on ports like Silverlight does, I set the site up on port 4505 (to fall within the 4502-4534 range). Nothing changed.
• Clearing cache and cookies in Internet options doesn’t seem to matter.
• Windows Firewall is off. Does Windows 8 have any other likely impediment to traffic? (Not that it should matter, because the desktop app works fine the whole time.)
• Windows Defender real-time protection is off.
• The behavior is the same even if I run the app on a simulator. I can’t test on another physical machine because this is my only dev install of Windows 8.

Hopefully this shows I have done due diligence on this. What have I missed? Please let me know if I can provide any more information.

Answer 1

Have you set intranet/internet network access for your application in its manifest?