Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I am currently unable to browse a website that is hosted on my EC2 instance (I get a 'could not connect' error).

I was trying to set up Node.js on my EC2 instance and as part of that process I executed the following command:

iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to 3000

Node.js worked fine but I wanted to remove the new rule I had created above. Eventually I realised executing the following would remove the rule:

iptables -t nat -D PREROUTING -p tcp --dport 80 -j REDIRECT --to 3000

However, after doing this I am still unable to browse the site.

I came across this answer to a similar problem and I have followed the steps outlined: http://serverfault.com/a/387774.

Firewall

  • I am allowing inbound traffic from all sources on TCP port 80.
  • I don't believe there are any iptable rules that would be blocking port 80. This is the output of iptables -nvL:
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination

Server issue

  • Apache is running on my instance and I have restarted it several times. This is the output of ps -ef | grep apache:
    root       630     1  0 19:29 ?        00:00:00 /usr/sbin/apache2 -k start
    www-data   665   630  0 19:29 ?        00:00:01 /usr/sbin/apache2 -k start
    www-data   666   630  0 19:29 ?        00:00:00 /usr/sbin/apache2 -k start
    www-data   667   630  0 19:29 ?        00:00:00 /usr/sbin/apache2 -k start
    www-data   668   630  0 19:29 ?        00:00:00 /usr/sbin/apache2 -k start
    www-data   671   630  0 19:29 ?        00:00:00 /usr/sbin/apache2 -k start
    www-data   878   630  0 19:44 ?        00:00:00 /usr/sbin/apache2 -k start
    www-data   879   630  0 19:44 ?        00:00:00 /usr/sbin/apache2 -k start
    www-data   880   630  0 19:44 ?        00:00:00 /usr/sbin/apache2 -k start
    ubuntu     896   760  0 20:15 pts/0    00:00:00 grep --color=auto apache
  • I have checked my 'ports.conf' file and Apache is set to listen to port 80. However, this is the output of netstat -pant | grep :80:
    (No info could be read for "-p": geteuid()=1000 but you should be root.)
    tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      - 

And lsof -Pnl +M -i4 gives me no entries. So, I am not sure if this is configured correctly. Apache isn't listening to any other ports.

Does anyone have any idea as to what the problem might be?

P.S. Before removing the iptables rule I did execute iptables -F. I'm not sure if that might have caused a problem.

P.P.S I was connecting to my instance via SSH with ssh -i mywebsite.pem ubuntu@<ip address of my instance>, however, whenever I do this it always times out. My workaround has been to replace the IP address with my instance's public DNS and that allows me to connect. I'm not sure if this is related or not.

Update:

With iptables -L -t nat I get:

Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination         

Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination 
 
share|improve this question
    
Try iptables -L -t nat –  Andrew Smith Jul 22 '12 at 20:50
    
@AndrewSmith Updated the answer with that. –  Stephen Young Jul 22 '12 at 20:58

2 Answers 2

From your post and follow-ups in the comments, it looks like you've done everything right. In my experience, this has meant I am missing something small and fundamental. Going on that premise, I see two things that could be giving you trouble:

  1. iptables - I have found the AWS Security Groups to be sufficient for firewall needs, so at least as an experiment you might turn off iptables to see if that gets you access to your webserver. You can start them up again immediately after the experiment if they're an important part of your security profile.
  2. IP address- you mention changing your ssh connection from instance IP to public DNS, which tells me you're running an Elastic IP, but you have not stated explicitly which IP address you are trying to use for the web connection. I have always found that once I associate an Elastic IP with an instance, I can no longer access that instance in any way via the internal IP. In this case that means several layers need to be in alignment: DNS and security rules allowing TCP/80 traffic to the server, firewall rules configured to allow traffic to that address, webserver configured to answer to that address (or 0.0.0.0).
share|improve this answer
    
Thanks for your response. Sorry it's taken me a while to get back to you. I've tried turning off iptables but I was still unable to access the web server. My instance's elastic IP address is 54.247.180.72. I was connecting with ssh via ubuntu@54.247.180.72 with no problems until now. I've tried to get Node running again but that doesn't work either now. I've also rebooted my instance but still no joy. I don't really know what else to do other than setting up a brand new instance unless you have any other ideas. –  Stephen Young Jul 25 '12 at 21:07
    
Wish I had other ideas for you, but one of the sweet things about AWS is the ease of spinning up a testbed to figure something out. I say do the rebuild thing and see if you can figure out something you overlooked. GL! –  khoxsey Jul 26 '12 at 3:46
up vote 0 down vote accepted

Turns out my elastic IP had become disassociated from my instance somehow. Reassociating it solved the problem.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.