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'm trying to build a CI server in a VM using CentOS 6 Minimalist Install and VirtualBox 4.1.4r74291 on a Windows 7 host box.

Before you ask:

  • selinux is currently disabled (with plans to re-enable once this problem is gone)
  • I can ssh into it, I can use git to push/pull from it
  • I can even use lynx to visit both localhost:80 and localhost:8080 within it. (I installed with 512MB of memory, so no GUI to do anything with.)
  • I can also ping/lynx google.com, etc.

Here's some command output:

ifconfig -a eth1
eth1      Link encap:Ethernet  HWaddr 08:00:27:2B:4E:3C
      inet addr:192.168.1.104  Bcast:192.168.1.255  Mask:255.255.255.0
      inet6 addr: fe80::a00:27ff:fe2b:4e3c/64 Scope:Link
      UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
      RX packets:320629 errors:0 dropped:0 overruns:0 frame:0
      TX packets:171826 errors:0 dropped:0 overruns:0 carrier:0
      collisions:0 txqueuelen:1000
      RX bytes:445888239 (425.2 MiB)  TX bytes:14540682 (13.8 MiB)

nmap localhost
    Nmap scan report for localhost (127.0.0.1)
    Host is up (0.0000080s latency).
    Hostname localhost resolves to 2 IPs. Only scanned 127.0.0.1
    Not shown: 994 closed ports
    PORT     STATE SERVICE
    22/tcp   open  ssh
    25/tcp   open  smtp
    80/tcp   open  http
    8009/tcp open  ajp13
    8080/tcp open  http-proxy
    9418/tcp open  git

    Nmap done: 1 IP address (1 host up) scanned in 0.09 seconds

iptables -vL
    Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
     pkts bytes target     prot opt in     out     source               destination
     315K  441M ACCEPT     all  --  any    any     anywhere             anywhere            state RELATED,ESTABLISHED
        0     0 ACCEPT     icmp --  any    any     anywhere             anywhere
     6010  281K ACCEPT     all  --  lo     any     anywhere             anywhere
        4   208 ACCEPT     tcp  --  any    any     anywhere             anywhere            state NEW tcp dpt:ssh
     8676  668K REJECT     all  --  any    any     anywhere             anywhere            reject-with icmp-host-prohibited

    Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
     pkts bytes target     prot opt in     out     source               destination
        0     0 REJECT     all  --  any    any     anywhere             anywhere            reject-with icmp-host-prohibited

    Chain OUTPUT (policy ACCEPT 184K packets, 13M bytes)
     pkts bytes target     prot opt in     out     source               destination

netstat -aln | grep 80
    tcp        0      0 :::8009                     :::*                        LISTEN
    tcp        0      0 :::8080                     :::*                        LISTEN
    tcp        0      0 :::80                       :::*                        LISTEN
    tcp        0      0 ::ffff:127.0.0.1:8005       :::*                        LISTEN
    unix  2      [ ACC ]     STREAM     LISTENING     8093   public/cleanup
    unix  3      [ ]         STREAM     CONNECTED     8099
    unix  3      [ ]         STREAM     CONNECTED     8098
    unix  3      [ ]         STREAM     CONNECTED     8096
    unix  3      [ ]         STREAM     CONNECTED     8095
    unix  3      [ ]         STREAM     CONNECTED     8092
    unix  3      [ ]         STREAM     CONNECTED     8091
    unix  3      [ ]         STREAM     CONNECTED     8089
    unix  3      [ ]         STREAM     CONNECTED     8088
    unix  2      [ ]         DGRAM                    8054
    unix  2      [ ]         DGRAM                    8013

And from the host:

telnet 192.168.1.104 80
    Could not open connection to the host, on port 80: Connect failed

So, both ports are open, and it looks like the firewall is allowing those ports to be connected to from the outside (yet, to be honest, I'm only guessing at that. I don't really know how to read the output from iptables -L.) Yet, whenever I try to visit 192.168.1.104:(80|8080) in Chrome from the host, I get the infamous:

Oops! Google Chrome could not connect to 192.168.1.104

This is possible, as I've done it before with a Kubuntu install (at .1.103, nonetheless), and I was attempting to move to a vm with a smaller memory footprint, and a bit more security.

Any suggestions? More info needed? I'm all ears at the moment.

EDIT:

After following Janne's answer, httpd is now listening on 192.168.1.104:80. As such, I can no longer lynx to localhost, and doing a wget 127.0.0.1 gives me a connection refused error. This is appropriate because now I have to lynx/wget 192.168.1.104 to get the results I was getting beforehand with 127.0.0.1 (The "It Works!" page from Apache and a download of index.html, respectively.) Another clue, perhaps?

share|improve this question
    
Could you add the output of netstat -aln | grep 80 –  Kenny Rasschaert Oct 24 '11 at 8:29
    
Done, sir. Hope it helps. –  Mike S Oct 24 '11 at 8:40
    
Do you have proxy configured in Chrome? What if you just telnet 192.168.1.104 80 from the host? –  Janne Pikkarainen Oct 24 '11 at 8:59
    
Chrome says that it's using my system proxy settings (and when I checked, there is no proxy set up, so I'm assuming it's not using one at all), and the telnet command output has been added to the question. Short answer: Connect Failed. Though I'm not surprised as telnet hasn't been set up on the vm (with no plans to, really.) –  Mike S Oct 24 '11 at 9:14
    
@Mike S: OK, wrote an answer to you. –  Janne Pikkarainen Oct 24 '11 at 9:19

2 Answers 2

up vote 3 down vote accepted

I don't see a rule in your iptable4s that will allow a connection on port 80 (except for the blanket allow on lo) Try opening port 80

iptables -I INPUT -p tcp -m tcp --dport 80 -j ACCEPT

or

iptables -I INPUT -i eth1 -p tcp -m tcp --dport 80 -j ACCEPT

if you want to limit access to connections on eth1.

share|improve this answer
    
Oh, so THAT'S how you kinda read iptables' output... Right on. Thanks a bunch! It works now, and that command also allowed me to open up port 8080 for initial Tomcat foolery. Thanks! –  Mike S Oct 24 '11 at 9:49
    
Don't forget to save your new ruleset service iptables save –  Iain Oct 24 '11 at 10:08
    
That's definitely a heck of a lot easier than editing the actual iptables file in /etc/sysconfig... Thanks again! –  Mike S Oct 24 '11 at 10:26

This is a wild shot in the dark: I guess your Apache is listening to 127.0.0.1 and not 192.168.1.104.

If netstat -tlnp returns that Apache is listening at 127.0.0.1:80, then it won't respond to eth1 traffic at all.

See Listen directive from your httpd.conf. It should say 192.168.1.104:80

EDIT: Hey, this must be about the iptables. When you say "I can use git", do you mean you use git over ssh?

Currently your iptables INPUT rules seem to be allowing new connections only to ssh port, and not to port 80. Try adding this to your iptables rules:

iptables -I INPUT 1 -i eth1 -p tcp -d 0/0 --dport 80 -j ACCEPT
share|improve this answer
    
netstat -tlnp returned that apache was listening on :::80. After setting the listen directive to 192.168.1.104:80, netstat -tlnp now shows it's listening on 192.168.1.104:80, but still no difference, even with IE or Firefox in brand-new sessions with cache cleared. Thanks for the shot though. Hopefully this will add another clue. –  Mike S Oct 24 '11 at 9:24
    
Interestingly though, attempting to do a wget 127.0.0.1/index.html now returns a connection refused error (where previously it would download index.html into whichever directory I was in... This will be added to the question.) –  Mike S Oct 24 '11 at 9:27
    
The original listen directive you had was actually better :-) :::80 means your Apache is listening to every network interface. –  Janne Pikkarainen Oct 24 '11 at 9:32
    
Well then that would explain why I can't use 127.0.0.1 all of a sudden, lol. It makes sense though. –  Mike S Oct 24 '11 at 9:34
    
Does wget 192.168.1.104/index.html work inside the VM? –  Janne Pikkarainen Oct 24 '11 at 9:38

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.