debian VM refusing all traffic apart from http

Question

I've got a VM with a fresh install of Debian (wheezy) and I've installed node and mongo on it. The VM is using a bridged network connection so I was expecting to be able to point my host machines browser at the ip address of the Debian VM (port 1337 for my node example or port 28017 for my mongo status page) and see one of the two services (node or mongo). My requests are refused though.

As far as I can tell Debian allows all traffic by default and you have to manually configure iptables to drop traffic. I've checked iptables and it says it's setup to allow anything through. It looks like this:

root@devbox:/home/jlewis# iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

As a test I setup nginx and I was able to get to the nginx landing page from my host no problems so obviously http traffic is allowed. I then set nginx up to forward all traffic upstream to mongo - no problems there, I was able to see the status page. I then did the same for my example node server and again, no problems. So http traffic is fine, but all other traffic is blocked.

Anyone know why debian might be refusing all other traffic other than iptables being setup to drop it?

EDIT - output from netstat -nltp:

Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0 127.0.0.1:28017         0.0.0.0:*               LISTEN      1762/mongod     
tcp        0      0 0.0.0.0:51028           0.0.0.0:*               LISTEN      1541/rpc.statd  
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      2462/sshd       
tcp        0      0 127.0.0.1:1337          0.0.0.0:*               LISTEN      2794/node       
tcp        0      0 127.0.0.1:25            0.0.0.0:*               LISTEN      2274/exim4      
tcp        0      0 127.0.0.1:27017         0.0.0.0:*               LISTEN      1762/mongod     
tcp        0      0 0.0.0.0:111             0.0.0.0:*               LISTEN      1510/rpcbind    
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      2189/nginx      
tcp6       0      0 :::22                   :::*                    LISTEN      2462/sshd       
tcp6       0      0 :::45335                :::*                    LISTEN      1541/rpc.statd  
tcp6       0      0 ::1:25                  :::*                    LISTEN      2274/exim4      
tcp6       0      0 :::111                  :::*                    LISTEN      1510/rpcbind

Theuni · Accepted Answer · 2012-12-06T21:43:56.403

1

I can't (yet) comment to ask for clarification ... still working on my reputation, but here it goes:

I can imagine the following things to help you find out:

try to verify that the processes don't only listen on localhost (netstat -nltp and/or nmap)
look closely at the error you get when trying to access the services: do the TCP SYN packages get lost? (tcpdump) or do you even get an ICMP response?

That should help you get more information and maybe refine the question.

[edit]

As the netstat output shows and as discussed in the comments: listening on 127.0.0.1 means they will only be reachable from localhost (as seen from the VM) and they should be either bound to 0.0.0.0 or the specific IP on the VM that is reachable from the physical host.

edited Dec 06 '12 at 21:43

answered Dec 06 '12 at 21:27

Theuni

958
5
15

Hi - I just stuck the output from netstat on my question. Looking at it, mongo and node listen on 127.0.0.1:PORT and nginx is on 0.0.0.0:PORT. This may seem like a naive question (I'm at a fairly beginner level here) but is that the problem? I should be on 0.0.0.0 instead of 127.0.0.1? Cheers, James. – james lewis Dec 06 '12 at 21:38
That's the problem. 0.0.0.0 means listen on all interfaces, addresses. 127.0.0.1 means only the loopback. – hookenz Dec 06 '12 at 21:42
Exactly. Or, better phrased: they should be bound to an adapter/NIC that is connected/routed from your outer/physical network. 0.0.0.0 means it will listen for connections to any interface/address. I generally recommend bind them to specific addresses. – Theuni Dec 06 '12 at 21:42
ok so actually setting up nginx and forwarding all traffic upstream was the way to go in the first place! – james lewis Dec 06 '12 at 21:49
Cheers for nmap by the way - it's telling me that the only open ports are 80, 22 and 111. If I try namp to port 1337 or 28017 it says they're closed. Cool! all making more sense now. Cheers, James – james lewis Dec 06 '12 at 21:50

score 1 · Answer 2 · answered Dec 06 '12 at 21:47

The ports you mention, 1337 and 28017, (as well as 25) are not listening on all interfaces, but only on 127.0.0.1, or localhost. So they cannot be accessed outside of the local machine. For security reasons, this is generally what you want.

By contrast, the services on port 22, 80, 111, 45335 and 51028 are bound to 0.0.0.0 or :: and are thus accessible to the world.

If you really mean for these services to be accessible to the world, you'll have to configure them as such, following their own respective configuration directives.

I'd setup nginx to forward all http traffic onto the services I wanted already but I didn't fully understand why I couldn't just access them in the first place without nginx. I'm all clued up now! Thanks for the help. James — james lewis, Dec 06 '12 at 21:53

debian VM refusing all traffic apart from http

2 Answers2