Azure outbound communication

Question

I'm having outbound communication issues on Ubuntu machines on the Azure service. I've setup the server using Ubuntu 14.04 (also tried 12.04) and I have no trouble SSHing into the machine or browsing to the machine. The trouble I have is when the application I have set up tries to connect to the MongoDB replica set it is unable to, throwing both:

pymongo.errors.AutoReconnect: [Errno 110] Connection timed out

and:

bson.errors.InvalidDocument: BSON document too large (7754 bytes)
    - the connected server supports BSON document sizes up to 0 bytes

Running mtr --report on the domain for the replica set and also for google or microsoft or stackoverflow or serverfault I always get the following returned:

Start: Fri Jul 25 09:35:38 2014
HOST: hostname                  Loss%   Snt   Last   Avg  Best  Wrst StDev

If I try to ping domains I get the following:

PING serverfault.com (198.252.206.16) 56(84) bytes of data.
^C
--- serverfault.com ping statistics ---
106 packets transmitted, 0 received, 100% packet loss, time 105135ms

I don't know where to go with this. Any help is greatly appreciated. It is a standard VM set up, ssh and https port open, no virtual network. If you need anything else let me know and I'll try provide them.

Answer 1

Azure doesn't support anything except TCP and UDP outside of a virtual network. For this reason you won't be able to use ping (ICMP) outbound. Traceroute will also not work (even if the outbound probes use TCP SYNs or UDP) since it depends on ICMP TTL Expired messages to get back to your host.

So, the ping and mtr you tried doesn't really mean anything. What you can try instead is something like "nc -vz www.serverfault.com 80" which would check to see if you can connect out on a web port. You should expect to see something like:

$ nc -vz www.serverfault.com 80
Connection to www.serverfault.com 80 port [tcp/www] succeeded!

As for communications between your application and your database, you've included far too little information here to properly troubleshoot this.

For some general pointers: If you had Application and Database servers on the same Azure virtual networks, you would be able to talk to your database by using the internal IP addresses in your virtual network. Since they're not on the same virtual network, you need to set up an endpoint on the database server and check your Access Control Lists (keeping in mind security requirements). This question may be helpful: https://stackoverflow.com/questions/13995734/azure-vms-virtual-network-inter-communication.