3

I am running a Windows Azure worker role which exposes a WCF service on port 1433, which is also defined to be an input TCP endpoint:

<InputEndpoint name="WcfServiceEndpoint" protocol="tcp" port="1433" />

The same worker role also exposes another service on TCP port 443, defined similarly:

<InputEndpoint name="TcpInterfaceEndpoint" protocol="tcp" port="443" />

I see both endpoints in the Management Portal, I am able to connect to the TcpInterfaceEndpoint at port 443 correctly, but I am not able to connect to the other port at all (tried from two different computers which are both able to access SQL servers outside, i.e. the port is not blocked for outgoing connections). When I tried to connect locally on the Azure instance (via Remote Desktop connection), telnet connected OK. Attempt to connect from elsewhere ends with “Connection timed out”. Everything seems to suggest port 1433 is handled differently to port 443, and is blocked by a firewall somewhere. I have even tried to completely disable Windows Firewall on the Azure instance, but nothing changed.

It would seem Azure is not allowing endpoints on port 1433 (which is normally MS SQL Server, we use it currently because of firewall restrictions in the testing environment), but I was not able to find any information on such limits anywhere. So – is it the case, or am I doing some trivial error somewhere?

Added: I tried another test: I switched both ports in the config file, so that WCF now runs at 443 and TCP at 1433. And, as I expected – the WCF service is available, while the TCP interface stops working. I am now quite convinced 1433 is, indeed, blocked in some way. It would just be fine to see this information documented somewhere.

Mormegil
  • 7,955
  • 4
  • 42
  • 77
  • 1433 shouldn't be blocked by the Compute firewall. Brent S (brentcodemonkey) has a service bus-sql example that does just this. Are you sure your WCF is successfully binding itself to that port? Does it work in local fabric? – Taylor Bird Mar 11 '11 at 20:36
  • Well... just for kicks, I pushed a worker role up with two mongodb instances - one on 27017 and one on 1433. I then RDP'd into my instance, watching both mongod server logs. The one listening on 1433 never received a connection request. I also explicitly opened 1433 on my instance's firewall. It's possible the load balancer handles this well-known port differently. As far as Service Bus goes, that goes through a different endpoint, so it might be handled differently. – David Makogon Mar 13 '11 at 14:54
  • Just curious - why are you attempting to hang a wcf service on the well-known sql server port? Proxy / router? – David Makogon Mar 13 '11 at 14:58
  • @David Makogon - As I have written, this is because of firewall restrictions in our testing environment. (The final production deployment will use a different port, so this is not a “showstopper” problem for us, just a nuisance.) – Mormegil Mar 13 '11 at 16:02
  • @Mormegil Ah - missed that detail. – David Makogon Mar 13 '11 at 20:42
  • @Taylor - I amended the question with another test. – Mormegil Mar 14 '11 at 10:07
  • Did you read this? http://stackoverflow.com/questions/5502729/how-to-access-sql-server-installed-on-azure-vm-vm-role-outside-of-vm – Muhammad Omar ElShourbagy Aug 06 '12 at 12:16

2 Answers2

5

Here's some documentation I ran across about the ports being closed (1433, 1434, 179).

Cause: Ports 179, 1433, and 1434 are blocked for public use in Windows Azure, so any connection between roles on these ports will be blocked and result in a time-out error.

Resolution: You must connect to endpoints using a set of ports that does not include ports 179, 1433, or 1434.

ryanjones
  • 5,383
  • 4
  • 28
  • 24
1

I can confirm ports 1433 and 1434 are blocked in Windows Azure today. The ports are blocked at the data center perimeter, so connections between roles on these ports will work. The set of blocked ports may change in the future.

Igor Dvorkin
  • 827
  • 1
  • 8
  • 18
  • Thanks, is that documented anywhere, or is this answer a result of your testing? – Mormegil Mar 26 '11 at 15:29
  • This is the result of my testing. I work on azure and can confirm today those ports are blocked. I can also confirm that today this is not documented. – Igor Dvorkin Mar 26 '11 at 20:56