6

I've noticed some issues with Apache virtual hosts on two Macs that otherwise have the same kind of set up (in terms of httpd.conf, vhosts, hosts etc.) On one Mac, virtual hosts are served without a glitch, on another, I am getting connection refused on port 80.

This doesn't seem to be a problem with Apache configuration, I think, but something to do with ports.

Namely, the machine that fails to serve the virtual host test.dev on 80 shows me this on port scan:

Сканирование портов выполняется…

Port Scanning host: 127.0.0.1

     Open TCP Port:     88          kerberos
     Open TCP Port:     445         microsoft-ds
     Open TCP Port:     548         afpovertcp
     Open TCP Port:     631         ipp
Сканирование портов завершено…

The machine that does serve test.dev show this:

Port Scanning host: 127.0.0.1

     Open TCP Port:     22          ssh
     Open TCP Port:     53          domain
     Open TCP Port:     80          http
     Open TCP Port:     88          kerberos
     Open TCP Port:     445         microsoft-ds
     Open TCP Port:     548         afpovertcp
     Open TCP Port:     631         ipp
Сканирование портов завершено…

So on the "good" machine, port 80 is listed, on the "bad" machine it isn't.

On both machines I have apache listening to *:80 etc, properly set up vhosts, an appropriate entry in the hosts file etc. Both Macs are running El Capitan, are on the same network etc.

And while on the good mac, test.dev is served, on the bad mac, I get this:

↪ curl -I -L test.dev                                                                                                                                                               15:51:01
curl: (7) Failed to connect to test.dev port 80: Connection refused

I'm at a bit of a loss, because I don't know how to fix this. Why is port 80 not showing up in the port scan of the bad Mac (using the Network Utility app), yet sudo lsof -i -P | grep -i "80"gives me:

httpd     4482           root    5u  IPv6 0xfe89d5ee2c7da24b      0t0  TCP *:80 (LISTEN)
httpd     4484         daemon    5u  IPv6 0xfe89d5ee2c7da24b      0t0  TCP *:80 (LISTEN)
httpd     4485         daemon    5u  IPv6 0xfe89d5ee2c7da24b      0t0  TCP *:80 (LISTEN)
httpd     4486         daemon    5u  IPv6 0xfe89d5ee2c7da24b      0t0  TCP *:80 (LISTEN)
httpd     4487         daemon    5u  IPv6 0xfe89d5ee2c7da24b      0t0  TCP *:80 (LISTEN)
httpd     4488         daemon    5u  IPv6 0xfe89d5ee2c7da24b      0t0  TCP *:80 (LISTEN)

Many thanks in advance.

All best, Tench

Edit: I was asked to justify why this is not a duplicate question to the more general question about connection refused. It isn't because my question was specific to Mac OSX and the solution that worked for me (see below) required editing pf.conf and using pfctl which is not mentioned in the supposed duplicate question at all.

Tench
  • 361
  • 2
  • 3
  • 8
  • 1
    It is a duplicate, the problem was a firewall which is listed in the answer. There are too many possible firewall configurations that could cause this problem so that case the best we can do is help someone figure out that it is a firewall and where it is. Once someone knows the source of the problem, they can take steps to fix it themselves or as a more focused question. – user9517 Dec 12 '15 at 12:14
  • This sounds like a firewall issue, especially the connection refused part. With no firewall present, the connection *usually* times out instead of being refused. Can you run `pfctl -s rules` on both Macs? Compare the differences and see if you can spot it. Here's the pfctl man page if you want to see more commands: https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man8/pfctl.8.html – Neil Dec 12 '15 at 07:36
  • thanks! i just came to the same conclusion myself and fixed it by explicitly opening port 80 in /etc/pf.conf – Tench Dec 12 '15 at 07:38
  • Again, here we have a concrete question about Mac OSX and a very concrete solution (my answer below, which involves pfctl). I don't see how a general question and a general answer ("it's a firewall issue") can be considered the same as a concrete question and a very concrete answer which fixes the problem for the particular operating system. The other thread DID NOT help me. This thread did. – Tench Dec 12 '15 at 16:29
  • @Neil I think you got this backwards: "With no firewall present, the connection *usually* times out instead of being refused." If the target host is up and the network connection is working, you are not supposed to be getting a connection time out. But a misconfigured firewall can cause a connection time out. – kasperd Dec 13 '15 at 08:51
  • @kasperd You're right. Not sure what I was thinking about. TCP sends a TCP refusal if no firewall + no listener. I'll delete that line. – Neil Dec 13 '15 at 09:30
  • @Tench Once you know that the issue is likely to be the firewall, the next question ought to be "How can I change the firewall setting son MacOSX". If you'd written that question and answer, it would most likely not get closed. It would also be helpful for people wanting to allow other connections than HTTP, and thus be more generally helpful. – Jenny D Dec 13 '15 at 10:29
  • @Tench Or you could simply add the mac-specific answer to the other question, making it useful for the next person. There's no reason at all to have a separate question for what is essentially the same issue. – Jenny D Dec 13 '15 at 10:30
  • 1
    I think you miss the point. If you take the position that the generic didn't work for you because Mac, then this answer is really only useful for port 80on a Mac. We now need to write Q&A for each and every port on a Mac. Then we'd need to move on to do the same for CentOS, Ubuntu et al which is ridiculous and where the generic Q&A comes in. If teh tools used in the generic are too Linux centric then adding a MaxOSX answer would be a great thing to do. – user9517 Dec 13 '15 at 14:00

1 Answers1

6

To make sure port 80 is open for TCP on all interfaces, I added

pass in proto tcp from any to any port 80

to /etc/pf.conf. Reloading pfctl didn't quite do the trick, but a reboot did. Now, the port shows up as open in port scan, and my virtual hosts are served as they should.

Tench
  • 361
  • 2
  • 3
  • 8
  • Thank you for the answer! (I didn't have to restart though, running `sudo pfctl -F all` worked for me). – Sheharyar Sep 24 '18 at 00:17
  • @Sheharyar it worked for you without a reboot because the command you ran actually removes all rules (including blocking ones). – Seb Jul 02 '20 at 21:18