If you have ever implemented a firewall in a traditional network, almost certainly it had at least two network interfaces. One was on an untrusted side, perhaps directly on the Internet, and the other was on a trusted side. The goal, of course, is to keep unwanted traffic from reaching the trusted network. There are more complex implementations, but this serves for illustration sake.
Traditional firewall configuration
I bring up these foundational topics to point out one way in which the public cloud makes us rethink our paradigms…in this case, that of the firewall. Continue reading →
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:
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. http://msdn.microsoft.com/en-us/library/sywbez17(v=vs.71).aspx
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: