/etc/rc.d/ipfw can't deal with firewall_type?

[Ian Smith]

On Wed, 4 May 2011, KIRIYAMA Kazuhiko wrote:
 > At Wed, 4 May 2011 03:47:02 +1000 (EST),
 > Ian Smith wrote:
 > > 
 > > On Wed, 4 May 2011, KIRIYAMA Kazuhiko wrote:
 > >  > Hi all,
 > >  > Recently I upgraded to 8.2-STABLE and reconfigured natd + jailed box, but
 > >  > all packets could not over nat box. I've researched and found
 > >  > /etc/rc.firewall does not recieve argument of firewall_type. So ipfw does
 > >  > not divert and natd could not be performed. The reason is /etc/rc.d/ipfw
 > >  > incorrect. I think an patch below should be applyed to /etc/rc.d/ipfw. Is
 > >  > there any problem to do this?
 > > 
 > > Yes.  Assuming using the default firewall_script="/etc/rc.firewall", 
 > > then as it says early in /etc/rc.firewall, you just needed to:
 > > 
 > > 	# Define the firewall type in /etc/rc.conf.  Valid values are:
 > > 	[..]
 > > 
 > > Sure, /etc/rc.firewall can set firewall_type to a parameter if you pass 
 > > it one, but otherwise uses whatever $firewall_type is set to when you 
 > > start ipfw.  I guess the code below allows you to use syntax like:
 > > 
 > >  # /etc/rc.d/ipfw start client

 > I missed it intended to use in commandline but usually /etc/rc.d/* script
 > uses at startup rc. If /etc/rc.d/ipfw must be 2 arguments,firewall_type
 > always undefined at startup nevertheless it specified in /etc/rc.conf. It
 > is the very serious problem isn't it?

/etc/rc.d/ipfw normally only takes one argument, {,quiet}start|stop|etc.  
The use of $1 in ipfw_start() surprised me actually, I'm only assuming 
its above intended use, but it's clearly an extra argument passed by rc, 
not the first argument to /etc/rc.d/ipfw itself (ie start|stop etc).  

Sorry to repeat, but normally firewall_type should be set in rc.conf - 
which works properly; no patching of /etc/rc.d/ipfw is needed.

 > > to override the $firewall_type set in /etc/rc.conf, but it's not the 
 > > common usage, nor is it how ipfw is started normally by rc.
 > > 
 > > So just set firewall_type in rc.conf and you should be fine .. unless 
 > > you meant that you're trying to run ipfw & natd INSIDE a jail?
 > 
 > The network being configure is as follows:
 >                                            xxxx.xxxx.xxxx.xxxx/27
 > -------------------------+----------------------------------------
 >                          |53
 >   +----------------------+---------------------------------------+
 >   |                    bge0                     jailed natd box  |
 >   |                t2.st.foo                     (ipfw `OPEN')   |
 >   |        +--------+--------+--------+--------+--------+--------+
 >   |firewall|   ns   |  ldap  |diskless|  mail  |  web   |  ftp   |
 >   |  bge1  |  bge1  |  bge1  |  bge1  |  bge1  |  bge1  |  bge1  |
 >   +----+---+----+---+----+---+----+---+----+---+----+---+----+---+
 >     254|       1|       2|       3|       4|       5|       6|
 > -------+--------+--------+--------+--------+--------+--------+----
 >                                                    192.168.2.0/24

I'm not entirely sure how to interpret your diagram, but as far as I am 
aware you can run neither ipfw nor natd within a jail; both scripts have 
'KEYWORD: nojail' so they won't be run on jail startup.  There's been 
mention of work underway with VIMAGE toward a full stack inside jail(s), 
but for now you can run ipfw (and natd) only on the host system.

 > >  > --- /etc/rc.d/ipfw.org	2011-05-03 18:19:28.000000000 +0900
 > >  > +++ /etc/rc.d/ipfw	2011-05-03 22:08:14.000000000 +0900
 > >  > @@ -35,15 +35,11 @@
 > >  >  
 > >  >  ipfw_start()
 > >  >  {
 > >  > -	local   _firewall_type
 > >  > -
 > >  > -	_firewall_type=$1
 > >  > -
 > >  >  	# set the firewall rules script if none was specified
 > >  >  	[ -z "${firewall_script}" ] && firewall_script=/etc/rc.firewall
 > >  >  
 > >  >  	if [ -r "${firewall_script}" ]; then
 > >  > -		/bin/sh "${firewall_script}" "${_firewall_type}"
 > >  > +		/bin/sh "${firewall_script}" "${firewall_type}"
 > >  >  		echo 'Firewall rules loaded.'
 > >  >  	elif [ "`ipfw list 65535`" = "65535 deny ip from any to any" ]; then
 > >  >  		echo 'Warning: kernel has firewall functionality, but' \
 > 
 > For the case of commandline usage, above patch should be modified as
 > follows:
 > 
 > --- /etc/rc.d/ipfw.org	2011-05-03 18:19:28.000000000 +0900
 > +++ /etc/rc.d/ipfw	2011-05-04 09:31:09.000000000 +0900
 > @@ -37,7 +37,11 @@
 >  {
 >  	local   _firewall_type
 >  
 > -	_firewall_type=$1
 > +	if [ -n "${1}" ]; then
 > +		_firewall_type=$1
 > +	elif [ -n "${firewall_type}" ]
 > +		_firewall_type=${firewall_type}
 > +	fi	
 >  
 >  	# set the firewall rules script if none was specified
 >  	[ -z "${firewall_script}" ] && firewall_script=/etc/rc.firewall

It's still unnecessary to mess with this.  See /etc/rc.firewall for its 
use of $firewall_type which may be set to open|closed|client|simple etc, 
or can be the full path to another script.  rc.firewall MAY also take a 
single parameter to override the firewall_type set in rc.conf, but again 
that's an override, not the regular usage.

cheers, Ian