Skip to main content

Windows 8 application returns “Unable to connect to the remote server” when sending requests to an internal test server

After weeks of testing, we were finally ready to release a first version of our Windows 8 app to our key user. So I created a package and copied all the files on an USB stick to ‘side load’ the application on his machine.  After running the Powershell installation script, installing the developer certificate,  the moment was finally there. The application started and the main hub was shown.

However the moment, the user started to click around and HttpWebRequests were send out to our backend services, the application failed with the following error message:

Unable to connect to the remote server

System.Exception {System.Net.WebException}

An attempt was made to access a socket in a way forbidden by its access permissions

We were clueless why it failed. We tested the application for weeks without any issue. The only difference is that we hosted the backend API somewhere else. Could this cause the issue? We were using a DNS that was mapped differently depending if you connect internally or externally.

The first thing we tried to do, was to add Fiddler into the mix to see what was going on. This made the experience even stranger because suddenly all web calls started to succeed?!            

In a desperate attempt, I opened up the Windows 8 manifest and added the capability for Private Networks:

PrivateNetworksWin8

The Private Networks (Client & Server capability provides inbound and outbound access to home and work networks through the firewall. This capability is typically used for games that communicate across the local area network (LAN), and for apps that share data across a variety of local devices. If your app specifies musicLibrary, picturesLibrary, or videosLibrary, you don't need to use this capability to access the corresponding library in a Home Group. Inbound access to critical ports is always blocked. The capability is written in the AppxManifest.xml file as the following code shows:

Afterwards the application worked fine.

Anyone with more insight who can explain why this solved the issue? I’m guessing this is required because the DNS is resolved to an internal network address…

Remark: To validate if my guess was correct, I removed the capability again and this time connected from outside our company network. I started the application and everything was working as expected.

Popular posts from this blog

Azure DevOps/ GitHub emoji

I’m really bad at remembering emoji’s. So here is cheat sheet with all emoji’s that can be used in tools that support the github emoji markdown markup: All credits go to rcaviers who created this list.

Kubernetes–Limit your environmental impact

Reducing the carbon footprint and CO2 emission of our (cloud) workloads, is a responsibility of all of us. If you are running a Kubernetes cluster, have a look at Kube-Green . kube-green is a simple Kubernetes operator that automatically shuts down (some of) your pods when you don't need them. A single pod produces about 11 Kg CO2eq per year( here the calculation). Reason enough to give it a try! Installing kube-green in your cluster The easiest way to install the operator in your cluster is through kubectl. We first need to install a cert-manager: kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.14.5/cert-manager.yaml Remark: Wait a minute before you continue as it can take some time before the cert-manager is up & running inside your cluster. Now we can install the kube-green operator: kubectl apply -f https://github.com/kube-green/kube-green/releases/latest/download/kube-green.yaml Now in the namespace where we want t...

Podman– Command execution failed with exit code 125

After updating WSL on one of the developer machines, Podman failed to work. When we took a look through Podman Desktop, we noticed that Podman had stopped running and returned the following error message: Error: Command execution failed with exit code 125 Here are the steps we tried to fix the issue: We started by running podman info to get some extra details on what could be wrong: >podman info OS: windows/amd64 provider: wsl version: 5.3.1 Cannot connect to Podman. Please verify your connection to the Linux system using `podman system connection list`, or try `podman machine init` and `podman machine start` to manage a new Linux VM Error: unable to connect to Podman socket: failed to connect: dial tcp 127.0.0.1:2655: connectex: No connection could be made because the target machine actively refused it. That makes sense as the podman VM was not running. Let’s check the VM: >podman machine list NAME         ...