A few days ago, something strange started to appear on my azure cloud service.
Every 25 seconds, a TCP connection from 13.95.160.11 is made.
It's an Microsoft Azure IP.
It has never done this before.
At first, I was thinking about a load balancer configuration but there is nothing about it in the documentation.
Here is my csdef Endpoints :
<Endpoints>
<InputEndpoint name="HttpEndpoint" protocol="http" port="8080" />
<InputEndpoint name="TcpEndpoint" protocol="tcp" port="12345"/>
<InternalEndpoint name="TcpInternal" protocol="tcp" />
</Endpoints>
I have also tried to downgrade my azure SDK from 2.9 to 2.8, but nothing change.
I don't know what I am missing, do you have any idea on what is happening?
I have the same problem and I asked on MSDN forums. This was the answer provided by a moderator:
IP address is related to Microsoft Azure in order to monitor the health (Keep connection alive).
Source.
Related
Is there any way to expose a microservice endpoint without port number in Azure Service Fabric? Port number can be defined in ServiceManifest.xml or it can be dynamically assigned by Service Fabric cluster, but how to call a service without specifying port number?
Of course you do not have to specify port number if you do not need it. Service Fabric will automatically assign port to your service. I also do not define port number because we have 100+ services and it is "a little bit hard" to do that
Just omit Port declaration in ServiceManifest.xml
<Resources>
<Endpoints>
<Endpoint Protocol="http" Name="UserHttpEndpoint" Type="Input" />
<Endpoint Protocol="tcp" Name="UserRpcEndpoint" Type="Input" />
</Endpoints>
</Resources>
An endpoint would be useless without a port. So even if you could have one, you shouldn't want it. You are probably looking for a way to call the service without knowing its port number. This can be achieved by using a reverse proxy. With a reverse proxy you can call a service by providing the port of the reverse proxy.
I started to play with Service Fabric very recently. I added a new Service Fabric cluster on Azure (unsecure) and I created a demo solution with 2 stateless Web API Services as follows:
Endpoint configuration for AnotherAPI is the following:
<Endpoints>
<!-- This endpoint is used by the communication listener to obtain the port on which to
listen. Please note that if your service is partitioned, this port is shared with
replicas of different partitions that are placed in your code. -->
<Endpoint Protocol="http" Name="ServiceEndpoint" Type="Input" Port="8698" />
</Endpoints>
I am able to access to the default controller (ValuesController) using the local endpoint:
http://localhost:8698/api/values
But when I try to use the azure endpoint I get an ERR_CONNECTION_TIMED_OUT error on Chrome.
http://{azure-ip-address}:8698/api/values
Is there anything that I am missing?
You have to open that port in your azure cluster via a Load Balancer Probe. You can do this at cluster creation time via ARM template or after the fact. For an existing cluster, go to the resource group, then the LB Balancer, then probes. The default open port in SF is 19080 though. If you just switch to that port it will work if you are not using SSL.
I'm trying to understand what are firewall rules for Azure cloud services (Web/Worker roles) by default, and I'm confused.
Based on multiple source, including this link http://download.microsoft.com/download/C/A/3/CA3FC5C0-ECE0-4F87-BF4B-D74064A00846/AzureNetworkSecurity_v3_Feb2015.pdf, inbound connections are blocked by default for cloud services, be it worker role or web role. To open inbound connection I would need to specify parameters for EndPoints elements in .cscfg.
However, I never did this, but my web roles and worker roles accept inboud connection, even UDP connection to worker role.
What am I missing?
Update: I apologize, I was looking at wrong file. For reasons I cannot explain I mixed .csdef and .cscfg. Now it looks like stupid question :)
You're correct - web and worker roles require endpoints to be defined, to allow external traffic to pass through to your role instances.
Regarding the fact you can currently access your existing web/worker instances: By default, an endpoint for port 80 is created for your web role, and if you enabled RDP, that is enabled as well.
Just be aware that there are port mappings that occur: That is, you specify the external port (maybe... port 8000), which then maps to your actual port where your code is listening (maybe... port 80).
And also be aware that, if you use one of those ports for one role, you must come up with a different port for a different role. All instances of a given role may consume the same port, in a load-balanced fashion. But... if you set up a web server using, say, port 8000 externally on your web role, and you define another web role (or maybe a worker role), you cannot use port 8000 for that role.
Role endpoints are exposed in the cloud service project, within Visual Studio, in case you don't want to edit the configuration file directly.
David has most of the answer covered, for the detailed WHY it works:
https://azure.microsoft.com/nl-nl/documentation/articles/cloud-services-role-enable-remote-desktop/
Take a look at the csdef file, there is an imports section in there
<Imports>
<Import moduleName="<import-module>"/>
</Imports>
The module for RDP is "RemoteAccess" and there will be a "RemoteAccessForwarder", all plugins/modules are in the Azure SDK in this directory (replace v2.9 with your azure SDK version)
C:\Program Files\Microsoft SDKs\Azure\.NET SDK\v2.9\bin\plugins
Importing this module results in the following config being added to the csdef file at runtime:
<?xml version="1.0" ?>
<RoleModule
xmlns="http://schemas.microsoft.com/ServiceHosting/2008/10/ServiceDefinition"
namespace="Microsoft.WindowsAzure.Plugins.RemoteAccess">
<Startup priority="-1">
<Task commandLine="RemoteAccessAgent.exe" executionContext="elevated" taskType="background" />
<Task commandLine="RemoteAccessAgent.exe /blockStartup" executionContext="elevated" taskType="simple" />
</Startup>
<ConfigurationSettings>
<Setting name="Enabled" />
<Setting name="AccountUsername" />
<Setting name="AccountEncryptedPassword" />
<Setting name="AccountExpiration" />
</ConfigurationSettings>
<Endpoints>
<InternalEndpoint name="Rdp" protocol="tcp" port="3389" />
</Endpoints>
<Certificates>
<Certificate name="PasswordEncryption" storeLocation="LocalMachine" storeName="My" permissionLevel="elevated" />
</Certificates>
</RoleModule>
This will open port 3389 for the RDP connection, so the Endpoint is in the .csdef file, but through an import.
Also take a look at the "RemoteForwarder", it acts as the gateway, so only 1 port (3389) has to be opened on the outside, and only 1 instance will listen to this. The RemoteForwarder will then forward the RDP connection to the right machine. More info:
https://blogs.msdn.microsoft.com/avkashchauhan/2011/12/06/how-does-remote-desktop-works-in-windows-azure/
About my case: I have a node.js REST API deployed in Azure CloudService. The node.js process is hosted in IIS using iisnode. Because of this the default probing doesn't work well as it might be that the entire IIS process is down or something when wrong in the node.exe process and the default probing will not encounter the issue. As a solution I am trying to implement custom probing.
The Problem: I am trying to make the Azure LoadBalancer use a custom probe endpoint for one of my CloudServices as discussed in this article. I am struggling with the fact that it seems custom LoadBalancing probes are available only for public input endpoints using http, tcp or udp.
In my case I have the limitation that I should expose only endpoints under the https protocol. Here is my CloudService definition:
<ServiceDefinition xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" name="dec-api-server" xmlns="http://schemas.microsoft.com/ServiceHosting/2008/10/ServiceDefinition">
<WebRole name="dec-api" vmsize="Small">
<Certificates>
<Certificate name="HttpsCertificate" storeLocation="LocalMachine" storeName="CA" />
</Certificates>
<Endpoints>
<InputEndpoint name="HttpsIn" protocol="https" port="443" certificate="HttpsCertificate"/>
<InputEndpoint name="internalProbingEndpoint" port="8091" protocol="http" loadBalancerProbe="customProbe"/>
</Endpoints>
<Sites>
<Site name="Web">
<Bindings>
<Binding name="HttpsIn" endpointName="HttpsIn" />
<Binding name="internalProbingBinding" endpointName="internalProbingEndpoint" />
</Bindings>
</Site>
</Sites>
</WebRole>
<LoadBalancerProbes>
<LoadBalancerProbe name="customProbe" intervalInSeconds="30" path="/probe" timeoutInSeconds="60" port="8091" protocol="http"/>
</LoadBalancerProbes>
</ServiceDefinition>
I have tried the following things:
I defined the loadBalancerProbe="customProbe" attribute in the httpsIn endpoint and modified protocol and the port in the LoadBalancerProbe element but it seems it is not possible as the deployment fails with a complain that it is not valid XML.protocol=https is not supported there.
Then I thought I can add second input endpoint using http that will be used for probing and will disable the network traffic for other networks using Endpoint ACL and allow only the LoadBalancer to access it. It works, or at least I can see in the IIS log that the LoadBalancer calls the /probe endpoint but in case it returns status 500 it takes out of rotation only this Endpoint but not the entire WebRole or Instance of the CloudService. The calls through the HttpsIn endpoint still hit the machine where the probe endpoint returns 500.
The Question: Is there a way to configure the Azure LoadBalancer for a CloudService to use a custom endpoint for probing when HTTPS is used?
Is there a workaround if that is not supported?
Any help or hint would be greatly appreciated.
Thanks
Is it possible to restrict the access to a Azure WebRole to a list of IP ranges.
I saw there are a number of articles explaining how to configure the firewall for accessing an SQL Azure instance but what about the WebRoles / WorkerRoles?
Thank you,
Luc
Since V1.3 of the SDK (and now V1.4), full IIS support and Startup tasks have been available to help solve this issue.
I've blogged about this http://blog.bareweb.eu/2011/04/restricting-access-by-ip-in-azure-web-role-v1-4/
You can use ipSecurity in web.config, but you must also do some work regarding installing the IPSec module into IIS.
Regards
Andy
Since Azure SDK 2.4 there has been a possibility to use Access Control List (ACL) to apply IP restrictions for your cloud services. I wrote a blog post on this: http://www.henrihietala.fi/apply-ip-restrictions-for-azure-cloud-service/
Just add the ACL in your ServiceConfiguration.Cloud.cscfg:
<?xml version="1.0" encoding="utf-8"?>
<ServiceConfiguration serviceName="MyWebRole.Azure" xmlns="http://schemas.microsoft.com/ServiceHosting/2008/10/ServiceConfiguration" osFamily="4" osVersion="*" schemaVersion="2014-06.2.4">
<Role name="MyWebRole">
...
</Role>
<NetworkConfiguration>
<AccessControls>
<AccessControl name="ipRestrictions">
<Rule action="permit" description="allowed-edu" order="100" remoteSubnet="137.133.228.111/32" />
<Rule action="permit" description="allowed-test" order="101" remoteSubnet="168.61.66.2/32" />
<Rule action="permit" description="allowed-prod" order="102" remoteSubnet="168.61.66.131/32" />
<Rule action="deny" description="Others" order="800" remoteSubnet="0.0.0.0/0" />
</AccessControl>
</AccessControls>
<EndpointAcls>
<EndpointAcl role="MyWebRole" endPoint="Endpoint1" accessControl="ipRestrictions" />
<EndpointAcl role="MyWebRole" endPoint="HttpsIn" accessControl="ipRestrictions" />
</EndpointAcls>
</NetworkConfiguration>
</ServiceConfiguration>
Be careful with rule attributes. Your deployment will fail if you have specified the same order number or description twice or the IP address in remoteSubnet is incorrect.
I have not personally done this in Azure yet, but have you tried just using the IIS7 IP security feature via the system.webServer/security/ipSecurity configuration element?
Microsoft provides the recipe for doing this in this May 2012 article http://msdn.microsoft.com/en-us/library/windowsazure/jj154098.aspx.
You can restrict a Windows Azure web role access to a set of specified IP addresses by modifying your IIS web.config file and creating a command file which unlocks the ipSecurity section of the ApplicationHost.config file.