Internal Endpoints and Firewall Rules with Windows Azure

I’ve learned a new lesson this past week on how Windows Azure configures firewall rules on the guest firewalls.

Configuring an internal endpoint creates the following rule in the guest OS:

•         NetTcpActivator
•         System
•         NetTcpPortSharing
•         CIS:{some-guid-representing-your-worker-role}

 Remote IP’s allowed are all of the role instances in your deployment.

The rule is configured to allow traffic for whatever port or port range you specified as the internal endpoint.

Many people have seen that “sometimes” the internal endpoint doesn’t work like they believe it does and that they have to manually open the port use netsh advfirewall firewall ……

The answer is the rule created by specifying the internal endpoint only applies to processes created from the role itself.

 So if you are creating a service and another process outside of the worker role is starting it you will not be able to access that service from the specified endpoint. In scenarios like this use the ServiceController class (in an elevated role of course) to start the service. 

For regular processes use the Process.Start() method. Both methods will allow other roles to access your endpoint without additional firewall configuration steps.

If you can’t control the starting of the service (such as COM+) you might have to open up some ports on the guest firewall through an elevated startup task – something like:

netsh advfirewall firewall add rule name=”YourRuleName” dir=in action=allow protocol=TCP localport=<yourport>