Debugging Port Problems

I’m playing with getting Insight deployed on EC2 and as with anything like this, there are an awful lot of variables when debugging issues. Specifically, for whatever reason I couldn’t access our Django instance on port 8000 despite what I thought was opening it up in the EC2 security group. Even more puzzling, Hudson, running on port 8080 was running just fine.

This can be a variety of things. First off, you need to make sure that Django is binding to the right IP address. This can be a bit tricky on EC2, as there are both public and private IPs. But this can easily be solved by binding to all interfaces, 0.0.0.0.

% ./python manage.py runserver 0.0.0.0:8000

Sadly, that didn’t fix things for me.

Next up, can we see the IP from the box itself? An easy way to test that is to log in and then try to telnet to the port, doing a simple GET for sanity:

% telnet localhost 8000
Trying 184.73.211.105...
Connected to ec2-184-73-211-105.compute-1.amazonaws.com (184.73.211.105).
Escape character is '^]'.
GET /


..
..

Ok, so that was working too. After verifying that the EC2 ports were indeed open and scratching my head further I decided to use a port scanner, namely nmap, to double check what ports were accessible, both from my machine at work, and from one of our other servers. That’s when I finally hit jackpot.

From one of our outside servers:

root@hq01-bot nicp]# nmap 184.73.211.105
Starting nmap 3.70 ( http://www.insecure.org/nmap/ ) at 2010-09-27 05:46 PDT
Interesting ports on ec2-184-73-211-105.compute-1.amazonaws.com (184.73.211.105):
(The 1656 ports scanned but not shown below are in state: filtered)
PORT     STATE  SERVICE
22/tcp   open   ssh
80/tcp   open   http
8000/tcp open   http-alt
8080/tcp closed http-proxy

And from my local box:

lagom:~ nicp$ nmap 184.73.211.105
Starting Nmap 5.21 ( http://nmap.org ) at 2010-09-27 14:46 CAT
Nmap scan report for ec2-184-73-211-105.compute-1.amazonaws.com        (184.73.211.105)
Host is up (0.32s latency).
Not shown: 997 filtered ports
PORT     STATE  SERVICE
22/tcp   open   ssh
80/tcp   open   http
8080/tcp closed http-proxy

So, sure enough, my work ISP is for some reason blocking port 8000, but not port 8080. Arr!

Well at least I know what the problem is now, and that’s half the battle. If that didn’t work, my next step would have been looking to see if my instance had any firewall enabled (Ubuntu doesn’t out of the box).