Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Very bizarre situation. I have inherited a few Xservers from a previous admin that I have been charged with cleaning up on various levels. I am familiar with settings in Ubuntu & am very comfortable with the command line—including compiling from source—on top of knowing how to maneuver around the command line in OS X as well. But have come across something utterly baffling on one of the servers which is running 10.6.8 (Snow Leopard).

First oddity, I would like to turn the software firewall completely off. Sounds as simple as going into Server Admin and just telling it to stop the firewall right? Nope! So if I turn off the firewall, and I do the following command to double check in the command line:

sysctl -a | grep net.inet.ip.fw.enable

The results are as expected:

net.inet.ip.fw.enable: 0

But then if I check it again within 5 minutes or so, it becomes magically enabled again:

net.inet.ip.fw.enable: 1

Ditto with NAT forwarding.

sysctl -a | grep net.inet.ip.forwarding

Disable it in the Server Admin, and this is the result:

net.inet.ip.forwarding: 0

A few minutes later:

net.inet.ip.forwarding: 1

WTF?!? I checked crontabs & I am the only user on the machine.

I do have the Server Admin app on another machine set to watch this machine, but it’s not running all of the time. And this issue did exist prior to that. I am not 10o% familiar with sysctl so need some guidance. FWIW, I do have some Ethernet tweaks I have set in /etc/sysctl.conf very recently, but no other commands or settings connected to the above.

Why would these settings seem to magically change after a few minutes? What can be done to stop that.

Thanks in advance for the help & pointers.

EDIT: Contents of /etc/hostconfig as per one of the comments below:

share|improve this question
Was Gateway Setup Assistant run on this server at some point (possibly implied as that'll configure the Firewall, NAT, and DHCP services)? – morgant Feb 5 '13 at 23:16
Thanks for the tip! No idea if Gateway Setup Assistant was run on the server. But being it is an “assistant” it would seem to me that whatever it did to configs can be rewound manually. But then again, no clue why it’s behaving that way. – JakeGould Feb 7 '13 at 16:44
what is the value of IPFILTER in the /etc/hostconfig file, immediately after you turn off firewall and after it enables itself? – Daniel t. Feb 7 '13 at 17:01
The only thing I've seen the firewall do automatically is re-open the port for serial number checks. You mentioned you've checked the crontabs, have you also checked /Library/LaunchDaemons/? – morgant Feb 7 '13 at 17:10
@Danielt. There is no entry for IPFILTER but there is an entry for IPFORWARDING and it is simply NO. I’ve posted the contents of the /etc/hostconfig in the main post for you to review. I don’t see anything significant. – JakeGould Feb 12 '13 at 2:14

Just a thought but you could use the tool auditctl to see what processes are touching your /etc/sysctl.conf.

You can read more about auditctl over in this thread:

Specifically this answer:

The gist is you run this command:

% sudo auditctl -p a -w /etc/sysctl.conf

And then watch the log file to see who's the guilty process:

% tail -f /var/log/audit/audit.log
share|improve this answer
??? My question has 100% nothing to do with /etc/sysctl.conf That simply has a few Etherenet tweaks. I’m the only person who has ever touched that file. That does not address the issue of the firewall & NAT router deciding to come back to life on their own. – JakeGould Feb 24 '13 at 9:00
I was showing you an approach to detect changes to files. If you're confident something isn't touching /etc/sysct.conf then watch other files! I do not have a Mac but you could potentially watch the files under /proc or /sys if OSX has those exposed by the kernel similar to Linux. – slm Feb 24 '13 at 14:15
up vote 0 down vote accepted

Okay, solved this one. Thanks for all of the advice folks!

What happened is there is a Java application running via a Mac shell program on this machine that has different options for creating a Jetty-based web interface. Somehow this was set to take over port 80—the standard HTTP port—and disabling that by changing the port URL to something else—like 666666—solved the issue. net.inet.ip.fw.enable and net.inet.ip.forwarding stay set at 0 (aka: disabled) and don’t come back to life when the port is changed to a non-standard port for HTTP purposes.

That said, I still need to have content delivered via a standard port 80 connection. So I turned on web services on the server & set a reverse proxy from that to port 666666. All behaves as it should.

But what is disturbing to me is how the application was able to takeover some sudo level functions—such as setting sysctl options—without seemingly ever asking for an admin password. Is that normal for Jetty apps or idiosyncratic to this app? Maybe it asked for an admin password when it was installed before I even go to it? Do not know or care for now. But clearing this up cleared up lots of networking issues on this box now that this application is no longer hijacking routing & firewall functions.

share|improve this answer
Performing root duties without having root would be a serious security issue, so it can be assumed that whatever your application is doing is doing it as root. Or it's not related to the problem at all, which seems more likely to me. – gparent Feb 25 '13 at 2:26
I can assure you that the problem is solved. Routing issues are now gone & networking behaves as expected for all services. The application acts as root for some other functions so the fact it has the capability to affect sysctl makes sense. But it still makes no sense. Not naming the app, but we are exploring replacements. And this maddening experience only adds fuel to the fire that it needs to be replaced or obsoleted ASAP. – JakeGould Feb 25 '13 at 2:36
Did you ever actually track the source? It might just be an impression, but from reading your post it seems to me like the exact cause of the problem was never found. I read it as "When this app starts it changes fw.enable and ip.forwarding but only when its port is used" which seems like awful behavior to me. – gparent Feb 25 '13 at 2:44
Yes, I tracked the source. It is this app. Every 5 minutes net.inet.ip.fw.enable and net.inet.ip.forwarding would magically restart despite system settings when this application ran with port 80. Switching it to use a non-standard port such as 666666 results in net.inet.ip.fw.enable and net.inet.ip.forwarding staying disabled & never magically coming back. I might do some disecting of the app itself to see if I can find the exact place where it sets this, but it is definitely this horrid application. – JakeGould Feb 25 '13 at 3:01

Your Answer


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.