Skip site navigation (1)Skip section navigation (2)

FreeBSD Manual Pages


home | help
ipftest(1)		    General Commands Manual		    ipftest(1)

       ipftest - test packet filter rules with arbitrary input.

       ipftest [ -6bdDoRvx ] [ -F input-format ] [ -i <filename> ] [ -I	inter-
       face ] [	-l <filename> ]	[ -N <filename>	]  [  -P  <filename>  ]	 [  -r
       <filename> ] [ -T <optionlist> ]

       ipftest is provided for the purpose of being able to test a set of fil-
       ter rules without having	to put them in place, in operation and proceed
       to  test	 their effectiveness.  The hope	is that	this minimises disrup-
       tions in	providing a secure IP environment.

       ipftest will parse any standard ruleset for use with ipf, ipnat	and/or
       ippool  and  apply  input, returning output as to the result.  However,
       ipftest will return one of three	values for packets passed through  the
       filter:	pass, block or nomatch.	 This is intended to give the operator
       a better	idea of	what is	happening with packets passing	through	 their
       filter ruleset.

       At least	one of -N, -P or -r must be specified.

       -6     Use IPv6.

       -b     Cause  the output	to be a	brief summary (one-word) of the	result
	      of passing the packet through the	filter;	either "pass", "block"
	      or "nomatch".  This is used in the regression testing.

       -d     Turn  on	filter rule debugging.	Currently, this	only shows you
	      what caused the rule to not match	in the IP header checking (ad-
	      dresses/netmasks,	etc).

       -D     Dump  internal  tables  before  exiting.	This excludes log mes-

       -F     This option is used to select which input	format the input  file
	      is  in.	The  following	formats	are available: etherfind, hex,
	      pcap, snoop, tcpdump,text.

		     The input file is to be text output from etherfind.   The
		     text  formats  which  are	currently  supported are those
		     which result from the following etherfind option combina-

			etherfind -n
			etherfind -n -t

	      hex    The  input	file is	to be hex digits, representing the bi-
		     nary makeup of the	packet.	 No length correction is made,
		     if	an incorrect length is put in the IP header.  A	packet
		     may be broken up over several  lines  of  hex  digits,  a
		     blank  line indicating the	end of the packet.  It is pos-
		     sible to specify both the interface name and direction of
		     the  packet  (for filtering purposes) at the start	of the
		     line using	this format: [direction,interface]  To	define
		     a	packet	going  in  on le0, we would use	[in,le0] - the
		     []'s are required and part	of the input syntax.

	      pcap The input file specified by -i is a	binary	file  produced
		     using  libpcap  (i.e.,  tcpdump  version 3).  Packets are
		     read from this file as being input	(for  rule  purposes).
		     An	interface maybe	specified using	-I.

	      snoop  The input file is to be in	"snoop"	format (see RFC	1761).
		     Packets are read from this	file and used  as  input  from
		     any  interface.   This  is	 perhaps the most useful input
		     type, currently.

		     The input file is to be text output  from	tcpdump.   The
		     text  formats  which  are	currently  supported are those
		     which result from the following tcpdump  option  combina-

			tcpdump	-n
			tcpdump	-nq
			tcpdump	-nqt
			tcpdump	-nqtt
			tcpdump	-nqte

	      text   The  input	file is	in ipftest text	input format.  This is
		     the default if no -F argument is specified.   The	format
		     used is as	follows:
			  "in"|"out" "on" if ["tcp"|"udp"|"icmp"]
			       srchost[,srcport] dsthost[,destport] [FSRPAU]

	      This  allows  for	 a  packet going "in" or "out" of an interface
	      (if) to be generated, being one of the three main	protocols (op-
	      tionally),  and  if  either TCP or UDP, a	port parameter is also
	      expected.	 If TCP	is selected, it	is  possible  to  (optionally)
	      supply TCP flags at the end.  Some examples are:
		   # a UDP packet coming in on le0
		   in on le0 udp,2210,23
		   # an	IP packet coming in on le0 from	localhost - hmm	:)
		   in on le0 localhost
		   # a TCP packet going	out of le0 with	the SYN	flag set.
		   out on le0 tcp,2245,23 S

       -i <filename>
	      Specify  the  filename  from  which  to  take input.  Default is

       -I <interface>
	      Set the interface	name (used in rule matching) to	 be  the  name
	      supplied.	  This is useful where it is not otherwise possible to
	      associate	a packet with an interface.  Normal "text packets" can
	      override this setting.

       -l <filename>
	      Dump  log	 messages  generated  during  testing to the specified

       -N <filename>
	      Specify the filename from	which to read NAT  rules  in  ipnat(5)

       -o     Save  output packets that	would have been	written	to each	inter-
	      face in a	file /tmp/interface_name in raw	format.

       -P <filename>
	      Read IP pool configuration information in	ippool(5) format  from
	      the specified file.

       -r <filename>
	      Specify  the  filename from which	to read	filter rules in	ipf(5)

       -R     Don't attempt to convert IP addresses to hostnames.

       -T <optionlist>
	      This option simulates the	run-time changing of  IPFilter	kernel
	      variables	 available  with the -T	option of ipf.	The optionlist
	      parameter	is a comma separated list of tuning commands.  A  tun-
	      ing  command  is either "list" (retrieve a list of all variables
	      in the kernel, their maximum, minimum and	current	value),	a sin-
	      gle  variable  name  (retrieve its current value)	and a variable
	      name with	a following assignment to set a	new value.  See	ipf(8)
	      for examples.

       -v     Verbose  mode.  This provides more information about which parts
	      of rule matching the input packet	passes and fails.

       -x     Print a hex dump of each packet before printing the decoded con-

       ipf(5), ipf(8), snoop(1m), tcpdump(8), etherfind(8c)

       Not  all	of the input formats are sufficiently capable of introducing a
       wide enough variety of packets for them to be all useful	in testing.



Want to link to this manual page? Use this URL:

home | help