Solved IPFW will not run script

[d33k4y]

Been working on this for awhile now. Every time I reboot and type ipfw list it always shows, "65535 deny ip from any to any", and of course all traffic is blocked, even thou I added

firewall_enable="YES"
firewall_type="/usr/local/etc/ipfw.rules"

to /etc/rc.conf I've also tried with

[...]
firewall_script="/usr/local/etc/ipfw.rules"

in place of firewall_type in /etc/rc.conf. I can manually start my rules by running sh /usr/local/etc/ipfw.rules but I cannot or do not want to have to do this every time.

The kernel was built with these lines in the conf:

options IPFIREWALL
options IPFIREWALL_VERBOSE
options IPFIREWALL_VERBOSE_LIMIT 10

What am I missing here? Please help!

 

[Jeckt]

firewall_type typically sets the firewall section used in /etc/rc.firewall, while firewall_script is used to specify a firewall script you created yourself. I'm pretty sure you don't want both at the same time, and it sounds like you only want the latter. (firewall_enable is required in either case)

This may be unrelated, but also set the first line of your script file to either be blank or set to #!/bin/sh . I'm thinking maybe it works manually because you're explicitly using the correct shell to execute it.

 

[d33k4y]

firewall_type is to designate the firewall section used in /etc/rc.firewall, while firewall_script is used to specify a firewall script you created yourself. You don't want both at the same time, and it sounds like you only want the latter. (firewall_enable is required in either case)

Yes I am only using one at a time but tried both, and it goes back to the default each time. My current /etc/rc.conf looks like this

firewall_enable="YES"
firewall_script="/usr/local/etc/ipfw.rules"

and for some reason it does not run the script. Does the script need specific permissions?

 

[Jeckt]

Nope, permissions are good (I use 644). I think this might be the time to go back to basics. Create a new firewall script with only:

#!/bin/sh
ipfw add allow all from any to any

in it, point firewall_script in rc.conf to that and see if that loads. If so, something about your script is causing the problem.

 

[d33k4y]

Nope, permissions are good (I use 644). I think this might be the time to go back to basics. Create a new firewall script with only:

#!/bin/sh
ipfw add allow all from any to any

in it, point firewall_script in rc.conf to that and see if that loads. If so, something about your script is causing the problem.

While that was an excellent idea, unfortunately it did the same thing. I Created test.rules with

#!/bin/sh
ipfw add 10 allow all from any to any

changed /etc/rc.conf to

firewall_enable="YES"
firewall_script="/usr/local/etc/test.rules"

and rebooted logged in and typed ipfw show and got 65535 deny ip from any to any only.

 

[Jeckt]

That narrows it down to an rc problem at least (ruling out an accidental flush somewhere). The only other thing I would think to check is the console on bootup. Sometimes this will spit out an error which isn't clear otherwise (use scroll-lock to scroll back in history after full boot). Aside from that maybe post your entire rc.conf (assuming you're not doing anything in rc.conf.d). As a temporary solution you could create a start/stop wrapper in /usr/local/etc/rc.d/ until the issue is resolved, but I'd only use that as a last resort.

 

[sidetone]

See what happens if you add flush to the top of your test rules.

 

[d33k4y]

So I overhauled /etc/rc.conf and changed the order to have

firewall_enable="YES"
firewall_script="/usr/local/etc/ipfw.rules"

before starting any other services and this seemed to work. Do theses lines have to before any other service in /etc/rc.conf?

 

[kpa]

So I overhauled /etc/rc.conf and changed the order to have

firewall_enable="YES"
firewall_script="/usr/local/etc/ipfw.rules"

before starting any other services and this seemed to work. Do theses lines have to before any other service in /etc/rc.conf?

The order of any settings in rc.conf(5) is totally irrelevant, it is read as a whole by the rc(8) system using the sh(1)'s . (source in some shells as well) operation.

 

[SirDice]

Order is indeed irrelevant. But this does sound like there's an error in your /etc/rc.conf that prevents reading these settings. Take a close look at the other settings, make sure everything is quoted properly.