No connection could be made because the target machine actively refused it when connecting to an Azure IP

4
votes

When connecting to an Azure active directory service (see code below) I promptly receive the error:

No connection could be made because the target machine actively refused it 191.235.135.139:443

Having googled the IP it resolves to a Azure data centre based in Ireland. Though what's really odd is as the IPs change from time to time, yesterday the Azure IP of 191.235.195.38:443 worked without any issues?

public partial class Startup
{
    public void ConfigureAuth(IAppBuilder app, HttpConfiguration config)
    {
        app.UseWindowsAzureActiveDirectoryBearerAuthentication(
            new WindowsAzureActiveDirectoryBearerAuthenticationOptions
            {
                Audience = CloudConfigurationManager.GetSetting("AzureActiveDirectoryInstance"),
                Tenant = CloudConfigurationManager.GetSetting("Tenant"),
                Provider = new QueryStringOAuthBearerProvider("AUTHORIZATION")
            });

        app.UseWebApi(config);
    }
}

I've searched high and low for answers, trying a whole range of suggestions such as checking nothing is using port 443 (the fact it tells me the target machine actively refused the connection leads me to believe that it's able to reach the machine).

I thought it could be to do with the Azure firewall but I have other colleagues that are able to connect to the service that are on the same public IP address.

Has anyone experienced this before when trying to connect to an Azure service?

1
c#.netazure
Ireland is an independent country. Some people would object strongly to any suggestion otherwise. – Richard
What values are you passing in with options? – Richard
Of course, thanks for catching that! – Joseph Woodward
In response to the values passed to options - I've updated the question to show the object being passed. Other colleagues working on the project have no problems connecting with them. – Joseph Woodward
@bytejunkie Yes, it turns out that it was our internal network firewall so I would check there. – Joseph Woodward

1 Answers

5
votes

After spending more time looking into this issue, it looked like the problem was because our internal network firewall was blocking access.