I just rented an Amazon EC2 server, made to host a node.js app which listen to client on port 9001.

I did configure the Security Groups and added inbound and outbound rules on this port. There is no firewall (Amazon Linux), and I completely disabled iptables.

A sudo netstat -plunta | grep LISTEN returns this :

tcp        0      0        *                   LISTEN      2064/sshd           
tcp        0      0      *                   LISTEN      2104/sendmail       
tcp        0      0      *                   LISTEN      3207/node           
tcp        0      0   *                   LISTEN      2146/mongod         
tcp        0      0 :::80                       :::*                        LISTEN      2303/httpd          
tcp        0      0 :::22                       :::*                        LISTEN      2064/sshd       

My node.js application is listening on this port and on all adresses, with the command server.listen(9001, "");

However, a nmap of the server returns this :

Portscan scan report for
Host is up.
All 1000 scanned ports on are filtered

Portscan done: 1 IP address (1 host up) scanned in 2.32 seconds

Alternatively, doing a nmap on my phone tells me that only port 80 is open.

If I run the node.js application on the server, and do a telnet <ip_server> 9001, it does work. However, if I do the same thing from my personal computer, I get a timeout error.

I know this question was addressed numerous times, but none of the solutions I have tried worked. I can ping the server, use ssh to connect to it, but the node.js application won't work, and any of the ports which should be open actually aren't (even trying to connect through a browser to the web server doesn't work, despite httpd being configured with a proper website, so port 80 isn't open either).

Any ideas on how to fix that?


1 Answer 1


All 1000 scanned ports on are filtered

As, indeed they should be.

There are several ranges of IPv4 addresses that are reserved for use on private networks.

172.16.*.* through 172.31.*.*

Any address in these ranges can't be directly accessed across the Internet.



EC2 instances always have a private IP address associated with them, and sometimes an externally-accessible public IP. These external addresses are either dynamically allocated at instance launch from a pool (and deallocated when the instance is stopped or terminated, at which point the address goes back to the pool), or can be continually reserved by the customer and associated/disassociated with instances and retained for the customer's subsequent reuse (in which case, they're called "Elastic IP Addresses.")

Internally to one customer's EC2 deployment in a given region (and across VPN tunnels into VPC) the instances can address each other by their private IP (and should, because it's free of data transport charges)... but across the Internet, instances can only be accessed by their public (a.k.a. "external") IP address, which is visible in the console... even though, from the instance's perspective (i.e. ifconfig, etc.) the only known address is the private one.

The EC2 infrastructure transparently does the network address translation (NAT) between the external public and the internal private address.

If you're accessing the instance by ssh from outside, the IP address you're using to establish the ssh connection will be the one you'll need to use to access other services, as well.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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