I cannot get Mac OS X Server's web server to accept connections from other machines on the same LAN. This is on OS X 10.8.2, running on a Mac mini which originally shipped with Lion Server.

I can connect to it from the server itself, such as by going to http://localhost or http://hostname.example.com in Safari.

Notice that connecting via the box's domain name works. This is because:

$ netstat -na | grep 80.*LISTEN
tcp46      0      0  *.80                   *.*                    LISTEN 

That is, Apache is listening on all interfaces, not just lo.

If I telnet server 80 from a client machine while doing a packet capture on both sides, I only see repeated TCP SYN packets. (server perspective, client perspective)

Disabling the firewall in the Security and Privacy settings pane doesn't change the symptom.

The firewall configuration looks harmless to me. (Dumped via pfctl -sa.)

I'm certain the problem isn't on the client side. I've tried accessing it from:

  • a month old iMac over GigE
  • a 2 year old MacBook Pro over WiFi
  • a 5 year old netbook running Ubuntu 12.04 over GigE and WiFi

This server is headless, and I do all my work on it from client machines on the LAN, via both SSH and VNC. This means that while I am failing to connect to this server on TCP port 80, I am successfully using it on TCP ports 22 and 5900. This behavior is what caused me to start looking at the firewall configuration.

Here's what the network looks like:

home office network

There are two network switches because this network is spread over two rooms, with one switch in each room and a single cable going between them. I ruled out the managed switch as the problem source with the WiFi test. I exonerated the dumb switch by temporarily running a long cable from the server to the managed switch.

The cable modem and the WiFi router (an AirPort Extreme) each have 4-port switches built in, but only one port on each is used, so no traffic goes through them that doesn't absolutely have to. The DHCP and caching DNS servers are turned off on both routers, since those duties are being done (successfully!) by the server in question. The AirPort is in bridging-only mode.

And yes, I've rebooted the server. And the clients. And the routers. And the switches. :)

My best guess is that the problem stems from having upgraded this box from Lion Server. If so, a complete reinstall will fix this, but that goes against all of my Unix server management training. I want to fix this server in place, if I can.

2 Answers 2


OS X actually has (at least) 3 firewalls. Since you've turned off the application firewall (in System Preferences -> Security & Privacy -> Firewall) and checked the Berkeley packet filter (pfctl -sa), I'm guessing it's the old ipfw that's doing the blocking. You can check with sudo ipfw show -- that'll list the active rules, along with counts of how many packets and bytes each one has applied to:

$ sudo ipfw show
01000 19228642 23229993542 allow ip from any to any via lo0
01010        0           0 deny ip from any to
65534    23505     3467352 deny ip from any to any
65535        0           0 allow ip from any to any

If your listing only shows rule #65535 (the allow rule at the end), my guess is wrong and you have to look elsewhere. If it does show other rules, you probably have a third-party firewall config program installed somewhere (I don't think the Apple-supplied ipfw config software is still there in 10.8); take a look in /Library/StartupItems and /Library/LaunchDaemons for things that might be relevant.

  • Your guess was right. The fix was sudo ipfw add 20000 allow tcp from any to any dst-port 80. I'm tempted to accept your answer as-is, but this feels like a hack rather than the real fix. Is there something I can ask the system to rebuild to sync the old firewall with the new, or cause it to stop using the old firewall? Mar 16, 2014 at 4:20
  • @WarrenYoung You'd have to track down what's activating it. ipfilter doesn't retain a setup itself; it has to be configured and activated after each reboot, so you'd need to track down what's activating it. Check /Library/StartupItems and /Library/LaunchDaemons for anything that might be turning it on. Also, see if an /etc/ipfilter folder exists -- that's where Apple used to store the config when their server software used it, and it's possible some standard system component would activate it based on the existence of that folder. Mar 16, 2014 at 5:13
  • Another right guess: /etc/ipfilter/ipfw.conf exists, and doesn't have a port 80 rule, but does have a deny-by-default rule at the end. Apparently ipfwmigrator didn't do the right thing when creating it when I upgraded OSes. Mar 16, 2014 at 5:20
  • @WarrenYoung In that case, I'll try for three in a row: if you remove that folder and reboot, does ipfw shut off? Mar 16, 2014 at 5:23
  • Home run. ipfw show says 65535 0 0 allow ip from any to any, while nmap server shows only expected open ports plus 488 filtered ports, indicating that the server does still have a running firewall. Mar 16, 2014 at 5:49

Open Console.app and check /var/log/appfirewall.log. You will be looking to see whether the connection request even reaches the app firewall. If it does reach there AND is allowed next check both /var/log/apache2/access_log and /var/log/apache2/error_log to see whether the request is reaching Apache. If the request is reaching Apache then the problem is likely in your Apache configuration file(s). If none of the above logs shows anything check the system.log for additional clues.

  • Re: logs: I get nothing in the logs when I try telnet server 80 from a client. But, I also get nothing when connecting to port 80 from an SSH session to that server. This is with the System Preferences firewall both off and on. So, it's not clear to me that the app firewall controls access to Apache at all. Feb 7, 2013 at 3:06
  • Re: Apache config files: I haven't touched them. Most of the timestamps are Aug 26 16:09, except for a few files which are even older. That's about three weeks before 10.8.2 came out, which is what this machine is running, so it's probably the date the Apple employee responsible for packaging Apache for OS X released the final package in the OS update. Also, bad Apache config doesn't explain why the server's network stack doesn't send out SYN-ACK packets. Feb 7, 2013 at 3:07
  • This is what shows up on my 10.8.2 system's appfirewall.log when connecting to it on port 80 from another machine on my home LAN. Feb 6 19:37:38 honeysmacks socketfilterfw[133] <Info>: Allow httpd connecting from to port 80 proto=6 and my Apache access_log shows - - [06/Feb/2013:19:37:46 -0800] "GET / HTTP/1.1" 200 44 Feb 7, 2013 at 3:42
  • Thanks for that. To answer the question, you'd need to explain why packets get into the server far enough for tshark to see them but not so far that the app firewall sees them, and how to fix that. Lacking that explanation, this info just puts a few grams on the balance scale pan marked "Nuke and pave, dude." Feb 7, 2013 at 4:21

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .