Which of the following is the most common format for IP addresses IPv4 TCP http IPF IPv6?

FreeBSD Manual Pages

IPF(5)			      File Formats Manual			IPF(5)

NAME
       ipf, ipf.conf - IPFilter	firewall rules file format

DESCRIPTION
       The ipf.conf file is used to specify rules for the firewall, packet au-
       thentication and	packet accounting  components  of  IPFilter.  To  load
       rules specified in the ipf.conf file, the ipf(8)	program	is used.

       For  use	 as a firewall,	there are two important	rule types: those that
       block and drop packets (block  rules)  and  those  that	allow  packets
       through	(pass  rules.) Accompanying the	decision to apply is a collec-
       tion of statements that specify under what conditions the result	is  to
       be applied and how.

       The  simplest  rules  that  can	be used	in ipf.conf are	expressed like
       this:

       block in	all
       pass out	all

       Each rule must contain at least the following three components

	      *	     a decision	keyword	(pass, block, etc.)

	      *	     the direction of the packet (in or	out)

	      *	     address patterns or "all" to match	any  address  informa-
		     tion

   Long	lines
       For  rules  lines  that	are particularly long, it is possible to split
       them over multiple lines	implicity like this:

       pass in on bgeo proto tcp from 1.1.1.1 port > 1000
	   to 2.2.2.2 port < 5000 flags	S keep state

       or explicitly using the backslash ('\') character:

       pass in on bgeo proto tcp from 1.1.1.1 port > 1000 \
	   to 2.2.2.2 port < 5000 flags	S keep state

   Comments
       Comments	in the ipf.conf	file are indicated by the use of the '#' char-
       acter.  This can	either be at the start of the line, like this:

       # Allow all ICMP	packets	in
       pass in proto icmp from any to any

       Or at the end of	a like,	like this:

       pass in proto icmp from any to any # Allow all ICMP packets in

Firewall rules
       This  section  goes into	detail on how to construct firewall rules that
       are placed in the ipf.conf file.

       It is beyond the	scope of this document to describe what	makes  a  good
       firewall	 rule  set  or	which packets should be	blocked	or allowed in.
       Some suggestions	will be	provided but further reading  is  expected  to
       fully understand	what is	safe and unsafe	to allow in/out.

   Filter rule keywords
       The  first  word	 found	in any filter rule describes what the eventual
       outcome of a packet that	matches	it will	be. Descriptions of  the  many
       and  various  sections  that  can  be  used to match on the contents of
       packet headers will follow on below.

       The complete list of keywords, along with what they do is as follows:

	      pass rules that match a packet  indicate	to  ipfilter  that  it
		     should  be	 allowed to continue on	in the direction it is
		     flowing.

	      block rules are used when	it is desirable	to  prevent  a	packet
		     from  going  any further. Packets that are	blocked	on the
		     "in" side are never seen by TCP/IP	 and  those  that  are
		     blocked going "out" are never seen	on the wire.

	      log  when	 IPFilter  successfully	matches	a packet against a log
		     rule a log	record is generated and	made available for ip-
		     mon(8)  to	read. These rules have no impact on whether or
		     not a packet is allowed through or	not.  So if  a	packet
		     first  matched  a block rule and then matched a log rule,
		     the status	of the packet after the	log rule  is  that  it
		     will still	be blocked.

	      count  rules provide the administrator with the ability to count
		     packets and bytes that match the criteria laid out	in the
		     configuration  file.   The	 count rules are applied after
		     NAT and filter rules on the inbound  path.	 For  outbound
		     packets,  count  rules  are applied before	NAT and	before
		     the packet	is dropped. Thus the count rule	cannot be used
		     as	a true indicator of link layer

	      auth  rules  cause  the matching packet to be queued up for pro-
		     cessing by	a user space program. The user	space  program
		     is	responsible for	making an ioctl	system call to collect
		     the information about the queued packet and another ioctl
		     system  call  to return the verdict (block, pass, etc) on
		     what to do	with the packet. In the	event that  the	 queue
		     becomes full, the packets will end	up being dropped.

	      call provides access to functions	built into IPFilter that allow
		     for more complex actions to be taken as part of the deci-
		     sion making that goes with	the rule.

	      decapsulate  rules instruct ipfilter to remove any other headers
		     (IP, UDP, AH) and then process what is inside  as	a  new
		     packet.   For  non-UDP  packets, there are	builtin	checks
		     that are applied in addition to whatever is specified  in
		     the  rule,	to only	allow decapsulation of recognised pro-
		     tocols. After decapsulating the inner packet, any filter-
		     ing  result  that	is applied to the inner	packet is also
		     applied to	the other packet.

	      The default way in which filter rules are	 applied  is  for  the
	      last  matching rule to be	used as	the decision maker. So even if
	      the first	rule to	match a	packet is a pass, if there is a	 later
	      matching	rule  that  is	a block	and no further rules match the
	      packet, then it will be blocked.

   Matching Network Interfaces
       On systems with more than one network interface,	it is necessary	to  be
       able  to	specify	different filter rules for each	of them.  In the first
       instance, this is because different networks will send us  packets  via
       each  network  interface	 but it	is also	because	of the hosts, the role
       and the resulting security policy that we need to be  able  to  distin-
       guish which network interface a packet is on.

       To accommodate systems where the	presence of a network interface	is dy-
       namic, it is not	necessary for the network interface named in a	filter
       rule  to	 be  present  in the system when the rule is loaded.  This can
       lead to silent errors being introduced and  unexpected  behaviour  with
       the simplest of keyboard	mistakes - for example,	typing in hem0 instead
       of hme0 or hme2 instead of hme3.

       On Solaris systems prior	to Solaris 10 Update 4,	it is not possible  to
       filter  packets	on  the	 loopback interface (lo0) so filter rules that
       specify it will have no impact on the corresponding  flow  of  packets.
       See below for Solaris specific tips on how to enable this.

       Some examples of	including the network interface	in filter rules	are:

       block in	on bge0	all
       pass out	on bge0	all

   Address matching (basic)
       The  first  and	most  basic part of matching for filtering rules is to
       specify IP addresses and	TCP/UDP	port numbers. The source  address  in-
       formation is matched by the "from" information in a filter rule and the
       destination address information is matched with the "to"	information in
       a filter	rule.

       The  typical format used	for IP addresses is CIDR notation, where an IP
       address (or network) is followed	by a '/' and a number representing the
       size  of	 the netmask in	bits. This notation is used for	specifying ad-
       dress matching in both IPv4 and IPv6. If	the '/'	and bitmask  size  are
       excluded	from the matching string, it is	assumed	that the address spec-
       ified is	a host address and that	the netmask applied should be all 1's.

       Some examples of	this are:

       pass in from 10.1.0.0/24	to any
       block out from any to 10.1.1.1

       It is not possible to specify a range of	addresses that does not	have a
       boundary	that can be defined by a standard subnet mask.

	      Names instead of addresses

	      Hostnames,  resolved  either  via	 DNS or	/etc/hosts, or network
	      names, resolved via /etc/networks, may be	used in	place  of  ac-
	      tual  addresses  in the filter rules. WARNING: if	a hostname ex-
	      pands to more than one address, only  the	 *first*  is  used  in
	      building the filter rule.

	      Caution should be	exercised when relying on DNS for filter rules
	      in case the sending and receiving	of DNS packets is blocked when
	      ipf(8)  is processing that part of the configuration file, lead-
	      ing to long delays, if not errors, in loading the	filter rules.

   Protocol Matching
       To match	packets	based on TCP/UDP port information, it is first	neces-
       sary  to	indicate which protocol	the packet must	be. This is done using
       the "proto" keyword, followed by	either the protocol number or  a  name
       which is	mapped to the protocol number, usually through the /etc/proto-
       cols file.

       pass in proto tcp from 10.1.0.0/24 to any
       block out proto udp from	any to 10.1.1.1
       pass in proto icmp from any to 192.168.0.0/16

   Sending back	error packets
       When a packet is	just discarded using a block rule, there is  no	 feed-
       back given to the host that sent	the packet. This is both good and bad.
       If this is the desired behaviour	and it is not desirable	 to  send  any
       feedback	about packets that are to be denied. The catch is that often a
       host trying to connect to a TCP port or with a  UDP  based  application
       will  send more than one	packet because it assumes that just one	packet
       may be discarded	so a retry is required.	The end	result being logs  can
       become cluttered	with duplicate entries due to the retries.

       To  address  this  problem,  a block rule can be	qualified in two ways.
       The first of these is specific to TCP and instructs  IPFilter  to  send
       back  a	reset (RST) packet. This packet	indicates to the remote	system
       that the	packet it sent has been	rejected and that  it  shouldn't  make
       any further attempts( to	send packets to	that port. Telling IPFilter to
       return a	TCP); RST packet in response to	something that	has  been  re-
       ceived is achieved with the return-rst keyword like this:

       block return-rst	in proto tcp from 10.0.0.0/8 to	any

       When  sending  back  a  TCP  RST	 packet, IPFilter must construct a new
       packet that has the source address of  the  intended  target,  not  the
       source address of the system it is running on (if they are different.)

       For  all	 of  the  other	protocols handled by the IP protocol suite, to
       send back an error indicating that the received packet was dropped  re-
       quires sending back an ICMP error packet. Whilst	these can also be used
       for TCP,	the sending host may not treat the received ICMP  error	 as  a
       hard error in( the same way as it does the TCP RST packet. To return an
       ICMP error); it is necessary to place return-icmp after the block  key-
       word like this:

       block return-icmp in proto udp from any to 192.168.0.1/24

       When( electing to return	an ICMP	error packet, it is also possible to);
       select what type	of ICMP	error is returned. Whilst the full  compliment
       of ICMP unreachable codes can be	used by	specifying a number instead of
       the string below, only the following should be used in conjunction with
       return-icmp.(  Which  return  code to use is a choice to	be made	when);
       weighing	up the pro's and con's.	Using some of the codes	 may  make  it
       more  obvious  that  a firewall is being	used rather than just the host
       not responding.

	      filter-prohib (prohibited	by filter) sending packets to the des-
		     tination  given  in the received packet is	prohibited due
		     to	the application	of a packet filter

	      net-prohib (prohibited network) sending packets to the  destina-
		     tion  given  in  the  received packet is administratively
		     prohibited.

	      host-unk (host unknown) the  destination	host  address  is  not
		     known  by	the  system receiving the packet and therefore
		     cannot be reached.

	      host-unr (host unreachable) it is	not possible to	reach the host
		     as	given by the destination address in the	packet header.

	      net-unk (network unknown)	the destination	network	address	is not
		     known by the system receiving the	packet	and  therefore
		     cannot be reached.

	      net-unr  (network	unreachable) it	is not possible	to forward the
		     packet on to its final destination	as given by the	desti-
		     nation address

	      port-unr	(port  unreachable)  there is no application using the
		     given destination port and	therefore it is	 not  possible
		     to	reach that port.

	      proto-unr	 (protocol  unreachable)  the IP protocol specified in
		     the packet	is not available to receive packets.

	      An example that shows how	to send	back a port unreachable	packet
	      for UDP packets to 192.168.1.0/24	is as follows:

	      block return-icmp(port-unr) in proto udp from any	to 192.168.1.0/24

	      In  the  above  examples,	when sending the ICMP packet, IPFilter
	      will construct a new ICMP	packet with a source  address  of  the
	      network  interface  used to send the packet back to the original
	      source. This can give away that there is an intermediate	system
	      blocking	packets. To have IPFilter send back ICMP packets where
	      the source address is the	original  destination,	regardless  of
	      whether  or  not it is on	the local host,	return-icmp-as-dest is
	      used like	this:

	      block return-icmp-as-dest(port-unr) in proto udp \
		  from any to 192.168.1.0/24

   TCP/UDP Port	Matching
       Having specified	which protocol is being	matched, it is	then  possible
       to indicate which port numbers a	packet must have in order to match the
       rule.  Due to port numbers being	used differently to addresses,	it  is
       therefore  possible to match on them in different ways. IPFilter	allows
       you to use the following	logical	operations:

       < x    is true if the port number is greater than or  equal  to	x  and
	      less than	or equal to y is true if the port number in the	packet
	      is less than x

       <= x   is true if the port number in the	packet is less than  or	 equal
	      to x

       > x    is true if the port number in the	packet is greater than x

       >= x   is  true if the port number in the packet	is greater or equal to
	      x

       = x    is true if the port number in the	packet is equal	to x

       != x   is true if the port number in the	packet is not equal to x

       Additionally, there are a number	of ways	to specify a range of ports:

       x <> y is true if the port number is less than a	and greater than y

       x >< y is true if the port number is greater than x and less than y

       x:y    is true if the port number is greater than or  equal  to	x  and
	      less than	or equal to y

       Some examples of	this are:

       block in	proto tcp from any port	>= 1024	to any port < 1024
       pass in proto tcp from 10.1.0.0/24 to any port =	22
       block out proto udp from	any to 10.1.1.1	port = 135
       pass in proto udp from 1.1.1.1 port = 123 to 10.1.1.1 port = 123
       pass in proto tcp from 127.0.0.0/8 to any port 6000:6009

       If  there is no desire to mention any specific source or	destintion in-
       formation in a filter rule then the word	"all" can be used to  indicate
       that all	addresses are considered to match the rule.

   IPv4	or IPv6
       If  a  filter  rule  is constructed without any addresses then IPFilter
       will attempt to match both IPv4 and IPv6	packets	with it. In  the  next
       list  of	 rules,	each one can be	applied	to either network protocol be-
       cause there is no address specified from	which IPFilter can derive with
       network protocol	to expect.

       pass in proto udp from any to any port =	53
       block in	proto tcp from any port	< 1024 to any

       To explicitly match a particular	network	address	family with a specific
       rule, the family	must be	added to the rule. For IPv4 it is necessary to
       add  family  inet  and  for IPv6, family	inet6. Thus the	next rule will
       block all packets (both IPv4 and	IPv6:

       block in	all

       but in the following example, we	block all IPv4 packets and only	 allow
       in IPv6 packets:

       block in	family inet all
       pass in family inet6 all

       To  continue  on	 from the example where	we allowed either IPv4 or IPv6
       packets to port 53 in, to change	that such that only  IPv6  packets  to
       port  53	need to	allowed	blocked	then it	is possible to add in a	proto-
       col family qualifier:

       pass in family inet6 proto udp from any to any port = 53

   First match vs last match
       To change the default behaviour from being the last  matched  rule  de-
       cides  the outcome to being the first matched rule, the word "quick" is
       inserted	to the rule.

Extended Packet	Matching
   Beyond using	plain addresses
       On firewalls that are working with large	numbers	of hosts and  networks
       or  simply trying to filter discretely against various hosts, it	can be
       an easier administration	task to	define a pool of addresses and have  a
       filter  rule  reference	that  address pool rather than have a rule for
       each address.

       In addition to being able to use	address	pools, it is possible  to  use
       the  interface  name(s) in the from/to address fields of	a rule.	If the
       name being used in the address section can be matched to	any of the in-
       terface	names mentioned	in the rule's "on" or "via" fields then	it can
       be used with one	of the following keywords for extended effect:

       broadcast use the primary broadcast address of  the  network  interface
	      for matching packets with	this filter rule;

	      pass in on fxp0 proto udp	from any to fxp0/broadcast port	= 123

       peer  use  the  peer  address  on point to point	network	interfaces for
	      matching packets with this filter	rule.  This  option  typically
	      only  has	 meaningful  use  with link protocols such as SLIP and
	      PPP.  For	example, this rule allows ICMP packets from the	remote
	      peer  of ppp0 to be received if they're destined for the address
	      assigned to the link at the firewall end.

	      pass in on ppp0 proto icmp from ppp0/peer	to ppp0/32

       netmasked use the primary network address, with	its  netmask,  of  the
	      network interface	for matching packets with this filter rule. If
	      a	network	interface had an IP address  of	 192.168.1.1  and  its
	      netmask was 255.255.255.0	(/24), then using the word "netmasked"
	      after the	interface name would match any	addresses  that	 would
	      match 192.168.1.0/24. If we assume that bge0 has this IP address
	      and netmask then the following two rules both serve  to  produce
	      the same effect:

	      pass in on bge0 proto icmp from any to 192.168.1.0/24
	      pass in on bge0 proto icmp from any to bge0/netmasked

       network using the primary network address, and its netmask, of the net-
	      work interface, construct	an address for exact  matching.	 If  a
	      network  interface has an	address	of 192.168.1.1 and its netmask
	      is 255.255.255.0,	using this option would	only match packets  to
	      192.168.1.0.

	      pass in on bge0 proto icmp from any to bge0/network

       Another	way  to	use the	name of	a network interface to get the address
       is to wrap the name in ()'s. In the above method, IPFilter looks	at the
       interface names in use and to decide whether or not the name given is a
       hostname	or network interface name. With	the use	of ()'s, it is	possi-
       ble  to	tell IPFilter that the name should be treated as a network in-
       terface name even though	it doesn't appear in the list of  network  in-
       terface that the	rule ias associated with.

	      pass in proto icmp from any to (bge0)/32

   Using address pools
       Rather  than list out multiple rules that either	allow or deny specific
       addresses, it is	possible to create a single object,  call  an  address
       pool,  that  contains  all of those addresses and reference that	in the
       filter rule. For	documentation on how to	write the  configuration  file
       for those pools and load	them, see ippool.conf(5) and ippool(8).	 There
       are two types of	address	pools that can be defined  in  ippool.conf(5):
       trees  and  hash	 tables. To refer to a tree defined in ippool.conf(5),
       use this	syntax:

       pass in from pool/trusted to any

       Either a	name or	number can be used after the '/', just so long	as  it
       matches	 up   with   something	 that  has  already  been  defined  in
       ipool.conf(5) and loaded	in with	ippool(8). Loading a filter rule  that
       references a pool that does not exist will result in an error.

       If  hash	tables have been used in ippool.conf(5)	to store the addresses
       in instead of a tree, then replace the word pool	with hash:

	      pass in from any to hash/webservers

       There are different operational characteristics with each, so there may
       be some situations where	a pool works better than hash and vice versa.

   Matching TCP	flags
       The  TCP	header contains	a field	of flags that is used to decide	if the
       packet is a connection request, connection termination, data, etc.   By
       matching	 on the	flags in conjunction with port numbers,	it is possible
       to restrict the way in which IPFilter allows connections	to be created.
       A  quick	 overview  of  the TCP flags is	below. Each is listed with the
       letter used in IPFilter rules, followed by its  three  or  four	letter
       pneumonic.

       S  SYN  -  this bit is set when a host is setting up a connection.  The
	      initiator	typically sends	a packet with the SYN bit and the  re-
	      sponder sends back SYN plus ACK.

       A  ACK  - this bit is set when the sender wishes	to acknowledge the re-
	      ceipt of a packet	from another host

       P PUSH -	this bit is set	when a sending host has	send some data that is
	      yet to be	acknowledged and a reply is sought

       F  FIN  -  this bit is set when one end of a connection starts to close
	      the connection down

       U URG - this bit	is set to indicate that	 the  packet  contains	urgent
	      data

       R  RST  -  this	bit is set only	in packets that	are a reply to another
	      that has been received but is not	targetted at any open port

       C CWN

       E ECN

       When matching TCP flags,	it is normal to	just list the  flag  that  you
       wish  to	 be set. By default the	set of flags it	is compared against is
       "FSRPAU". Rules that say	"flags S" will be displayed by	ipfstat(8)  as
       having  "flags  S/FSRPAU". This is normal.  The last two	flags, "C" and
       "E", are	optional - they	may or may not be used by an end host and have
       no  bearing on either the acceptance of data nor	control	of the connec-
       tion. Masking them out with "flags S/FSRPAUCE" may cause	 problems  for
       remote hosts making a successful	connection.

       pass in quick proto tcp from any	to any port = 22 flags S/SAFR
       pass out	quick proto tcp	from any port =	22 to any flags	SA

       By  itself, filtering based on the TCP flags becomes more work but when
       combined	with stateful filtering	(see below), the situation changes.

   Matching on ICMP header information
       The TCP and UDP are not the only	protocols for which  filtering	beyond
       just  the  IP  header is	possible, extended matching on ICMP packets is
       also available. The list	of valid ICMP types is different for  IPv4  vs
       IPv6.

       As  a  practical	 example,  to allow the	ping command to	work against a
       specific	target requires	allowing two different types of	ICMP  packets,
       like this:

       pass in proto icmp from any to webserver	icmp-type echo
       pass out	proto icmp from	webserver to any icmp-type echorep

       The  ICMP header	has two	fields that are	of interest for	filtering: the
       ICMP type and code. Filter rules	can accept either a name or number for
       both  the  type and code. The list of names supported for ICMP types is
       listed below, however only ICMP unreachable  errors  have  named	 codes
       (see above.)

       The  list  of ICMP types	that are available for matching	an IPv4	packet
       are as follows:

       echo (echo request), echorep (echo  reply),  inforeq  (information  re-
       quest),	inforep	 (information  reply), maskreq (mask request), maskrep
       (mask reply), paramprob (parameter problem), redir (redirect), routerad
       (router	advertisement),	 routersol  (router  solicit), squence (source
       quence),	timest (timestamp), timestreq (timestamp reply),  timex	 (time
       exceeded), unreach (unreachable).

       The  list  of ICMP types	that are available for matching	an IPv6	packet
       are as follows:

       echo (echo request), echorep (echo reply), fqdnquery (FQDN query), fqd-
       nreply  (FQDN  reply), inforeq (information request), inforep (informa-
       tion reply), listendone (MLD listener done), listendqry	(MLD  listener
       query),	listendrep  (MLD  listener  reply), neighadvert	(neighbour ad-
       vert), neighborsol (neighbour solicit), paramprob (parameter  problem),
       redir  (redirect),  renumber (router renumbering), routerad (router ad-
       vertisement), routersol (router solicit), timex (time exceeded),	toobig
       (packet	too  big),  unreach (unreachable, whoreq (WRU request),	whorep
       (WRU reply).

Stateful Packet	Filtering
       Stateful	packet filtering is where IPFilter remembers some  information
       from  one  or  more packets that	it has seen and	is able	to apply it to
       future packets that it receives from the	network.

       What this means for each	transport layer	protocol  is  different.   For
       TCP  it means that if IPFilter sees the very first packet of an attempt
       to make a connection, it	has enough information to allow	all other sub-
       sequent packets without there needing to	be any explicit	rules to match
       them. IPFilter uses the TCP port	numbers, TCP flags,  window  size  and
       sequence	numbers	to determine which packets should be matched. For UDP,
       only the	UDP port numbers are available.	 For ICMP, the ICMP types  can
       be  combined  with  the	ICMP id	field to determine which reply packets
       match a request/query that has already been seen. For all other	proto-
       cols,  only matching on IP address and protocol number is available for
       determining if a	packet received	is a mate to one that has already been
       let through.

       The  difference this makes is a reduction in the	number of rules	from 2
       or 4 to 1. For example, these 4 rules:

       pass in on bge0 proto tcp from any to any port =	22
       pass out	on bge1	proto tcp from any to any port = 22
       pass in on bge1 proto tcp from any port = 22 to any
       pass out	on bge0	proto tcp from any port	= 22 to	any

       can be replaced with this single	rule:

       pass in on bge0 proto tcp from any to any port =	22 flags S keep	state

       Similar rules for UDP and ICMP might be:

       pass in on bge0 proto udp from any to any port =	53 keep	state
       pass in on bge0 proto icmp all icmp-type	echo keep state

       When using stateful filtering with TCP it is best to add	"flags	S"  to
       the  rule  to  ensure  that state is only created when a	packet is seen
       that is an indication of	a new connection. Although IPFilter can	gather
       some  information  from packets in the middle of	a TCP connection to do
       stateful	filtering, there are some options that are only	 sent  at  the
       start  of  the  connection which	alter the valid	window of what TCP ac-
       cepts. The end result of	trying to pickup TCP state in  mid  connection
       is  that	 some  later  packets  that are	part of	the connection may not
       match the known state information and be	dropped	 or  blocked,  causing
       problems.  If  a	 TCP  packet matches IP	addresses and port numbers but
       does not	fit into the recognised	window,	it will	not  be	 automatically
       allowed	and  will  be  flagged	inside	of IPFitler as "out of window"
       (oow). See below, "Extra	packet attributes", for	how to match  on  this
       attribute.

       Once  a	TCP  connection	has reached the	established state, the default
       timeout allows for it to	be idle	for 5 days before it is	 removed  from
       the  state table. The timeouts for the other TCP	connection states vary
       from 240	seconds	to 30 seconds.	Both UDP and ICMP state	 entries  have
       asymetric  timeouts  where  the	timeout	set upon seeing	packets	in the
       forward direction is much larger	than for the  reverse  direction.  For
       UDP the default timeouts	are 120	and 12 seconds,	for ICMP 60 and	6 sec-
       onds. This is a reflection of the use of	these protocols	being more for
       query-response  than  for ongoing connections.  For all other protocols
       the timeout is 60 seconds in both directions.

   Stateful filtering options
       The following options can be used with stateful filtering:

       limit limit the number of state table entries that this rule can	create
	      to  the number given after limit.	A rule that has	a limit	speci-
	      fied is always permitted that many state table entries, even  if
	      creating	an additional entry would cause	the table to have more
	      entries than the otherwise global	limit.

	      pass ... keep state(limit	100)

       age sets	the timeout for	the state entry	when  it  sees	packets	 going
	      through  it.  Additionally  it is	possible to set	the tieout for
	      the reply	packets	that come back through the firewall to a  dif-
	      ferent value than	for the	forward	path. allowing a short timeout
	      to be set	after the reply	has been seen and the state no	longer
	      required.

	      pass in quick proto icmp all icmp-type echo \
		  keep state (age 3)
	      pass in quick proto udp from any \
		  to any port =	53 keep	state (age 30/1)

       strict  only  has  an  impact when used with TCP. It forces all packets
	      that are allowed through the firewall to be sequential:  no  out
	      of order delivery	of packets is allowed. This can	cause signifi-
	      cant slowdown for	some connections and  may  stall  others.  Use
	      with caution.

	      pass in proto tcp	... keep state(strict)

       noicmperr  prevents  ICMP  error	packets	from being able	to match state
	      table entries created with this flag using the contents  of  the
	      original packet included.

	      pass ... keep state(noicmperr)

       sync  indicates to IPFilter that	it needs to provide information	to the
	      user land	daemons	responsible for	syncing	other  machines	 state
	      tables up	with this one.

	      pass ... keep state(sync)

       nolog  do  not generate any log records for the creation	or deletion of
	      state table entries.

	      pass ... keep state(nolog)

       icmp-head rather	than just precent ICMP error packets from  being  able
	      to  match	state table entries, allow an ACL to be	processed that
	      can filter in or out ICMP	error packets based as you would  with
	      normal  firewall	rules.	The icmp-head option requires a	filter
	      rule group number	or name	to be present, just as you  would  use
	      with head.

	      pass in quick proto tcp ... keep state(icmp-head 101)
	      block in proto icmp from 10.0.0.0/8 to any group 101

       max-srcs	 allows	 the  number of	distinct hosts that can	create a state
	      entry to be defined.

	      pass ... keep state(max-srcs 100)
	      pass ... keep state(limit	1000, max-srcs 100)

       max-per-src whilst max-srcs limits the number of	individual hosts  that
	      may cause	the creation of	a state	table entry, each one of those
	      hosts is still table to fill up the state	table with new entries
	      until the	global maximum is reached. This	option allows the num-
	      ber of state table entries per address to	be limited.

	      pass ... keep state(max-srcs 100,	max-per-src 1)
	      pass ... keep state(limit	100, max-srcs 100, max-per-src 1)

	      Whilst these two rules might seem	identical, in that  they  both
	      ultimately  limit	 the  number  of hosts and state table entries
	      created from the rule to 100, there is a subtle difference:  the
	      second  will  always  allow  up to 100 state table entries to be
	      created whereas the first	may not	if the state  table  fills  up
	      from other rules.

	      Further, it is possible to specify a netmask size	after the per-
	      host limit that enables the per-host limit to become a  per-sub-
	      net or per-network limit.

	      pass ... keep state(max-srcs 100,	max-per-src 1/24)

	      If  there	 is  no	IP protocol implied by addresses or other fea-
	      tures of the rule, IPFilter will assume that no  netmask	is  an
	      all ones netmask for both	IPv4 and IPv6.

   Tieing down a connection
       For  any	 connection that transits a firewall, each packet will be seen
       twice: once going in and	once going out.	Thus a connection has 4	 flows
       of packets:

       forward inbound packets

       forward outbound	packets

       reverse inbound packets

       reverse outbound	packets

       IPFilter	 allows	 you to	define the network interface to	be used	at all
       four points in the flow of packets. For rules that match	inbound	 pack-
       ets,  out-via  is  used to specify which	interfaces the packets go out,
       For rules that match outbound packets, in-via is	used to	match the  in-
       bound packets.  In each case, the syntax	generalises to this:

       pass ...	in on forward-in,reverse-in \
	      out-via forward-out,reverse-out ...

       pass ...	out on forward-out,reverse-out \
		in-via forward-in,reverse-in ...

       An  example that	pins down all 4	network	interfaces used	by an ssh con-
       nection might look something like this:

       pass in on bge0,bge1 out-via bge1,bge0 proto tcp	\
	   from	any to any port	= 22 flags S keep state

   Working with	packet fragments
       Fragmented packets result in 1 packet containing	all of the layer 3 and
       4  header information whilst the	data is	split across a number of other
       packets.

       To enforce access control on fragmented packets,	one of two  approaches
       can  be	taken. The first is to allow through all of the	data fragments
       (those that made	up the body of the original packet) and	rely on	match-
       ing  the	 header	 information in	the "first" fragment, when it is seen.
       The reception of	body fragments without the first will  result  in  the
       receiving  host	being  unable  to completely reassemble	the packet and
       discarding all of the fragments.	The following  three  rules  deny  all
       fragmented  packets  from  being	received except	those that are UDP and
       even then only allows those destined for	port 2049 to be	completed.

       block in	all with frags
       pass in proto udp from any to any with frag-body
       pass in proto udp from any to any port =	2049 with frags

       Another mechanism that is available is to track "fragment state".  This
       relies  on  the first fragment of a packet that arrives to be the frag-
       ment that contains all of the layer 3 and layer 4  header  information.
       With  the  receipt of that fragment before any other, it	is possible to
       determine which other fragments are to be allowed through without need-
       ing  to	explicitly allow all fragment body packets.  An	example	of how
       this is done is as follows:

       pass in proto udp from any port = 2049 to any with frags	keep frags

Building a tree	of rules
       Writing your filter rules as one	long list of rules can be both ineffi-
       cient  in terms of processing the rules and difficult to	understand. To
       make the	construction of	filter rules easier, it	is possible  to	 place
       them in groups.	A rule can be both a member of a group and the head of
       a new group.

       Using filter groups requires at least two rules:	one to be in the group
       one  one	 to  send matchign packets to the group. If a packet matches a
       filtre rule that	is a group head	but does not match any of the rules in
       that  group,  then  the	packet	is considered to have matched the head
       rule.

       Rules that are a	member of a group contain the word group  followed  by
       either a	name or	number that defines which group	they're	in. Rules that
       form the	branch point or	starting point for the group must use the word
       head, followed by either	a group	name or	number.	If rules are loaded in
       that define a group but there is	no matching head then they will	effec-
       tively  be  orphaned  rules.  It	is possible to have more than one head
       rule point to the same group, allowing groups to	be used	 like  subrou-
       tines to	implement specific common policies.

       A common	use of filter groups is	to define head rules that exist	in the
       filter "main line" for each direction with the interfaces in  use.  For
       example:

       block in	quick on bge0 all head 100
       block out quick on bge0 all head	101
       block in	quick on fxp0 all head internal-in
       block out quick on fxp0 all head	internal-out
       pass in quick proto icmp	all icmp-type echo group 100

       In  the	above set of rules, there are four groups defined but only one
       of them has a member rule. The  only  packets  that  would  be  allowed
       through	the above ruleset would	be ICMP	echo packets that are received
       on bge0.

       Rules can be both a member of a group and the head of a new group,  al-
       lowing groups to	specialise.

       block in	quick on bge0 all head 100
       block in	quick proto tcp	all head 1006 group 100

       Another use of filter rule groups is to provide a place for rules to be
       dynamically added without needing to worry about	their specific	order-
       ing amongst the entire ruleset. For example, if I was using this	simple
       ruleset:

       block in	quick all with bad
       block in	proto tcp from any to any port = smtp head spammers
       pass in quick proto tcp from any	to any port = smtp flags S keep	state

       and I was getting lots of connections to	my email server	from  10.1.1.1
       to  deliver  spam,  I  could  load the following	rule to	complement the
       above:

	      block in quick from 10.1.1.1 to any group	spammers

   Decapsulation
       Rule groups also	form a different  but  vital  role  for	 decapsulation
       rules.	With  the  following  simple  rule, if IPFilter	receives an IP
       packet that has an AH header as its layer 4 payload, IPFilter would ad-
       just  its view of the packet internally and then	jump to	group 1001 us-
       ing the data beyond the AH header as the	new transport header.

       decapsulate in proto ah all head	1001

       For protocols that are recognised as being used with tunnelling or oth-
       erwise  encapsulating  IP protocols, IPFilter is	able to	decide what it
       has on the inside without any assistance. Some tunnelling protocols use
       UDP  as	the  transport mechanism. In this case,	it is necessary	to in-
       struct IPFilter as to what protocol is inside UDP.

       decapsulate l5-as(ip) in	proto udp from any \
	   to any port = 1520 head 1001

       Currently IPFilter only supports	finding	IPv4 and IPv6 headers directly
       after the UDP header.

       If  a  packet  matches a	decapsulate rule but fails to match any	of the
       rules that are within the specified group,  processing  of  the	packet
       continues  to the next rule after the decapsulate and IPFilter's	inter-
       nal view	of the packet is returned to what it was prior to the decapsu-
       late rule.

       It  is  possible	to construct a decapsulate rule	without	the group head
       at the end that ipf(8) will accept but such rules will  not  result  in
       anything	happening.

   Policy Based	Routing
       With firewalls being in the position they often are, at the boundary of
       different networks connecting together and  multiple  connections  that
       have  different	properties, it is often	desirable to have packets flow
       in a direction different	to what	the routing table instructs  the  ker-
       nel.  These decisions can often be extended to changing the route based
       on both source and destination address or even port numbers.

       To support this kind of configuration, IPFilter	allows	the  next  hop
       destination  to	be specified with a filter rule. The next hop is given
       with the	interface name to use for output. The syntax for this  is  in-
       terface:ip.address.  It	is expected that the address given as the next
       hop is directly connected to the	network	to which the interface is.

       pass in on bge0 to bge1:1.1.1.1 proto tcp \
	   from	1.1.2.3	to any port = 80 flags S keep state

       When this feature is combined with stateful filtering, it becomes  pos-
       sible  to  influence  the network interface used	to transmit packets in
       both directions because we now have a sense for what its	 reverse  flow
       of packets is.

       pass in on bge0 to bge1:1.1.1.1 reply-to	hme1:2.1.1.2 \
	   proto tcp from 1.1.2.3 to any port =	80 flags S keep	state

       If  the	actions	of the routing table are perfectly acceptable, but you
       would like to mask the presence of the firewall by not changing the TTL
       in  IP  packets	as they	transit	it, IPFilter can be instructed to do a
       "fastroute" action like this:

       pass in on bge0 fastroute proto icmp all

       This should be used with	caution	as  it	can  lead  to  endless	packet
       loops.  Additionally,  policy  based  routing  does  not	 change	the IP
       header's	TTL value.

       A variation on this type	of rule	supports a duplicate of	 the  original
       packet being created and	sent out a different network. This can be use-
       ful for monitoring traffic and other purposes.

       pass in on bge0 to bge1:1.1.1.1 reply-to	hme1:2.1.1.2 \
	   dup-to fxp0:10.0.0.1	proto tcp from 1.1.2.3 \
	   to any port = 80 flags S keep state

   Matching IPv4 options
       The design for IPv4 allows for the header to be	upto  64  bytes	 long,
       however most traffic only uses the basic	header which is	20 bytes long.
       The other 44 bytes can be uesd to store IP options. These  options  are
       generally  not necessary	for proper interaction and function on the In-
       ternet today. For most people it	is sufficient to block	and  drop  all
       packets that have any options set. This can be achieved with this rule:

       block in	quick all with ipopts

       This  rule  is  usually	placed towards the top of the configuration so
       that all	incoming packets are blocked.

       If you wanted to	allow in a specific IP option type, the	syntax changes
       slightly:

       pass in quick proto igmp	all with opt rtralrt

       The  following  is  a list of IP	options	that most people encounter and
       what their use/threat is.

       lsrr (loose source route) the sender of the packet includes a  list  of
	      addresses	 that  they wish the packet to be routed through to on
	      the way to the destination. Because replies to such packets  are
	      expected	to  use	 the list of addresses in reverse, hackers are
	      able to very effectively	use  this  header  option  in  address
	      spoofing attacks.

       rr  (record route) the sender allocates some buffer space for recording
	      the IP address of	each router that the packet goes through. This
	      is most often used with ping, where the ping response contains a
	      copy of all addresses from  the  original	 packet,  telling  the
	      sender  what  route the packet took to get there.	Due to perfor-
	      mance and	security issues	with IP	header options,	this is	almost
	      no longer	used.

       rtralrt	(router	alert) this option is often used in IGMP messages as a
	      flag to routers that the packet needs to be handled differently.
	      It  is  unlikely	to ever	be received from an unknown sender. It
	      may be found on LANs or otherwise	controlled networks where  the
	      RSVP protocol and	multicast traffic is in	heavy use.

       ssrr  (strict source route) the sender of the packet includes a list of
	      addresses	that they wish the packet to be	routed through	to  on
	      the  way	to  the	 destination. Where the	lsrr option allows the
	      sender to	specify	only some of the  nodes	 the  packet  must  go
	      through,	with  the  ssrr	 option, every next hop	router must be
	      specified.

       The complete list of IPv4 options that can be  matched  on  is:	addext
       (Address	Extention), cipso (Classical IP	Security Option), dps (Dynamic
       Packet State), e-sec (Extended Security), eip (Extended Internet	Proto-
       col),  encode  (ENCODE),	 finn  (Experimental Flow Control), imitd (IMI
       Traffic Descriptor), lsrr (Loose	Source Route), mtup (MTU Probe - obso-
       lete),  mtur (MTU response - obsolete), nop (No Operation), nsapa (NSAP
       Address), rr (Record Route),  rtralrt  (Router  Alert),	satid  (Stream
       Identifier),  sdb  (Selective Directed Broadcast), sec (Security), ssrr
       (Strict Source Route), tr (Tracerote), ts  (Timestamp),	ump  (Upstream
       Multicast  Packet), visa	(Experimental Access Control) and zsu (Experi-
       mental Measurement).

   Security with CIPSO and IPSO
       IPFilter	supports filtering on IPv4 packets using  security  attributes
       embedded	 in  the IP options part of the	packet.	These options are usu-
       ally only used on networks and systems that are using lablled security.
       Unless  you know	that you are using labelled security and your network-
       ing is also labelled, it	is highly unlikely that	this section  will  be
       relevant	to you.

       With  the traditional IP	Security Options (IPSO), packets can be	tagged
       with a security level. The following keywords are recognised and	 match
       with  the relevant RFC with respect to the bit patterns matched:	confid
       (confidential), rserve-1	(1st reserved value), rserve-2	(2nd  reserved
       value),	rserve-3  (3rd reserved	value),	rserve-4 (4th reserved value),
       secret (secret),	topsecret (top secret),	unclass	(unclassified).

       block in	quick all with opt sec-class unclass
       pass in all with	opt sec-class secret

   Matching IPv6 extension headers
       Just as it is possible to filter	on the various IPv4 header options, so
       too  it	is  possible  to filter	on the IPv6 extension headers that are
       placed between the IPv6 header and the transport	protocol header.

       dstopts (destination options), esp (encrypted, secure,  payload),  frag
       (fragment),  hopopts (hop-by-hop	options), ipv6 (IPv6 header), mobility
       (IP mobility), none, routing.

   Logging
       There are two ways in which packets can be logged  with	IPFilter.  The
       first  is with a	rule that specifically says log	these types of packets
       and the second is a qualifier to	one of the other keywords. Thus	it  is
       possible	to both	log and	allow or deny a	packet with a single rule.

       pass in log quick proto tcp from	any to any port	= 22

       When  using  stateful filtering,	the log	action becomes part of the re-
       sult that is remembered about a packet. Thus  if	 the  above  rule  was
       qualified  with	keep  state,  every  packet in the connection would be
       logged. To only log the first packet from  every	 packet	 flow  tracked
       with  keep state, it is necessary to indicate to	IPFilter that you only
       wish to log the first packet.

       pass in log first quick proto tcp from any to any port =	22 \
	   flags S keep	state

       If it is	a requirement that the logging provide an accurate representa-
       tion  of	which connections are allowed, the log action can be qualified
       with the	option or-block. This allows the administrator to instruct IP-
       Filter  to  block the packet if the attempt to record the packet	in IP-
       Filter's	kernel log records (which have an upper	bound on size) failed.
       Unless  the  system shuts down or reboots, once a log record is written
       into the	kernel buffer, it is there until ipmon(8) reads	it.

       block in	log proto tcp from any to any port = smtp
       pass in log or-block first quick	proto tcp from any \
	   to any port = 22 flags S keep state

       By default, IPFilter will only log the header portion of	a  packet  re-
       ceived  on  the network.	Up to 128 bytes	of a packet's body can also be
       logged with the body keyword. ipmon(8) will display the contents	of the
       portion of the body logged in hex.

       block in	log body proto icmp all

       When  logging packets from ipmon(8) to syslog, by default ipmon(8) will
       control what syslog facility and	priority a packet will be logged with.
       This can	be tuned on a per rule basis like this:

       block in	quick log level	err all	with bad
       pass in log level local1.info proto tcp \
	   from	any to any port	= 22 flags S keep state

       ipfstat(8)  reports  how	many packets have been successfully logged and
       how many	failed attempts	to log a packet	there were.

   Filter rule comments
       If there	is a desire to associate a text	string,	be it  an  administra-
       tive  comment or	otherwise, with	an IPFilter rule, this can be achieved
       by giving the filter rule a comment.  The comment is  loaded  with  the
       rule  into  the	kernel	and can	be seen	when the rules are listed with
       ipfstat.

       pass in quick proto tcp from any	\
	   to port = 80	comment	"all web server	traffic	is ok"
       pass out	quick proto tcp	from any port =	80 \
	   to any comment "all web server traffic is ok"

   Tags
       To enable filtering and NAT to correctly	match up packets  with	rules,
       tags  can be added at with NAT (for inbound packets) and	filtering (for
       outbound	packets.) This allows a	filter to be correctly mated with  its
       NAT  rule  in  the  event that the NAT rule changed the packet in a way
       that would mean it is not obvious what it was.

       For inbound packets, IPFilter can match the  tag	 used  in  the	filter
       rules  with that	set by NAT. For	outbound rules,	it is the reverse, the
       filter sets the tag and the NAT rule matches up with it.

       pass in ... match-tag(nat=proxy)
       pass out	... set-tag(nat=proxy)

       Another use of tags is to supply	a number that is only used  with  log-
       ging.  When packets match these rules, the log tag is carried over into
       the log file records generated by ipmon(8). With	 the  correct  use  of
       tools such as grep, extracting log records of interest is simplified.

       block in	quick log ... set-tag(log=33)

Filter Rule Expiration
       IPFilter	 allows	 rules to be added into	the kernel that	it will	remove
       after a specific	period of time by specifying rule-ttl at the end of  a
       rule.   When  listing  rules in the kernel using	ipfstat(8), rules that
       are going to expire will	 NOT  display  "rule-ttl"  with	 the  timeout,
       rather what will	be seen	is a comment with how many ipfilter ticks left
       the rule	has to live.

       The time	to live	is specified in	seconds.

       pass in on fxp0 proto tcp from any \
	   to port = 22	flags S	keep state rule-ttl 30

Internal packet	attributes
       In addition to being able to filter on very specific network and	trans-
       port  header  fields, it	is possible to filter on other attributes that
       IPFilter	attaches to a packet. These attributes are placed  in  a  rule
       after  the  keyword  "with",  as	 can  be seen with frags and frag-body
       above. The following is a list of the other attributes available:

       oow the packet's	IP addresses and TCP ports match an existing entry  in
	      the  state  table	 but  the sequence numbers indicate that it is
	      outside of the accepted window.

	      block return-rst in quick	proto tcp from any to any with not oow

       bcast this is set by IPFilter when it receives  notification  that  the
	      link  layer packet was a broadcast packet. No checking of	the IP
	      addresses	is performned to determine if it is a broadcast	desti-
	      nation or	not.

	      block in quick proto udp all with	bcast

       mcast  this  is	set by IPFilter	when it	receives notification that the
	      link layer packet	was a multicast	packet.	No checking of the  IP
	      addresses	is performned to determine if it is a multicast	desti-
	      nation or	not.

	      pass in quick proto udp from any to any port = dns with mcast

       mbcast can be used to match a packet that  is  either  a	 multicast  or
	      broadcast	 packet	at the link layer, as indicated	by the operat-
	      ing system.

	      pass in quick proto udp from any to any port = ntp with mbcast

       nat the packet positively matched a NAT table entry.

       bad sanity checking of the packet failed. This could indicate that  the
	      layer 3/4	headers	are not	properly formed.

       bad-src	when  reverse  path verification is enabled, this flag will be
	      set when the interface the packet	is received on does not	 match
	      that  which  would be used to send a packet out of to the	source
	      address in the received packet.

       bad-nat an attempt to perform NAT on the	packet failed.

       not each	one of the attributes matched using  the  "with"  keyword  can
	      also be looked for to not	be present. For	example, to only allow
	      in good packets, I can do	this:

       block in	all
       pass in all with	not bad

Tuning IPFilter
       The ipf.conf file can also be used to tune the behaviour	 of  IPFilter,
       allowing,  for  example,	 timeouts for the NAT/state table(s) to	be set
       along with their	sizes. The presence and	names of tunables  may	change
       from  one  release  of  IPFilter	 to the	next. The tunables that	can be
       changed via ipf.conf is the same	as those that can be seen and modified
       using the -T command line option	to ipf(8).

       NOTE:  When  parsing  ipf.conf,	ipf(8)	will apply the settings	before
       loading any rules. Thus if your settings	are at the top,	these  may  be
       applied	whilst the rules not applied if	there is an error further down
       in the configuration file.

       To set one of the values	below, the syntax is simple:  "set",  followed
       by the name of the tuneable to set and then the value to	set it to.

       set state_max 9999;
       set state_size 10101;

       A list of the currently available variables inside IPFilter that	may be
       tuned from ipf.conf are as follows:

       active set through -s command line switch of ipf(8). See	ipf(8) for de-
	      tals.

       chksrc  when set, enables reverse path verification on source addresses
	      and for filters to match packets with bad-src attribute.

       control_forwarding when set turns off kernel forwarding	when  IPFilter
	      is disabled or unloaded.

       default_pass  the  default  policy  -  whether  packets	are blocked or
	      passed, etc - is represented by the value	of this	 variable.  It
	      is  a  bit  field	 and  the  bits	 that  can be set are found in
	      <netinet/ip_fil.h>. It is	not recommended	to tune	this value di-
	      rectly.

       ftp_debug  set  the  debugging level of the in-kernel FTP proxy.	 Debug
	      messages will be printed to the system console.

       ftp_forcepasv when set the FTP proxy must see a PASV/EPSV  command  be-
	      fore creating the	state/NAT entries for the 227 response.

       ftp_insecure  when  set the FTP proxy will not wait for a user to login
	      before allowing data connections to be created.

       ftp_pasvonly when set the proxy will not	create state/NAT  entries  for
	      when it sees either the PORT or EPRT command.

       ftp_pasvrdr  when  enabled causes the FTP proxy to create very insecure
	      NAT/state	entries	that will allow	 any  connection  between  the
	      client  and server hosts when a 227 reply	is seen.  Use with ex-
	      treme caution.

       ftp_single_xfer when set	the FTP	proxy will only	allow one data connec-
	      tion at a	time.

       hostmap_size  sets  the	size of	the hostmap table used by NAT to store
	      address mappings for use with sticky rules.

       icmp_ack_timeout	default	timeout	used for ICMP NAT/state	when  a	 reply
	      packet is	seen for an ICMP state that already exists

       icmp_minfragmtu	sets  the minimum MTU that is considered acceptable in
	      an ICMP error before deciding it is a bad	packet.

       icmp_timeout default timeout used for ICMP NAT/state  when  the	packet
	      matches the rule

       ip_timeout  default  timeout  used  for	NAT/state entries that are not
	      TCP/UDP/ICMP.

       ipf_flags

       ips_proxy_debug this sets the debugging level  for  the	proxy  support
	      code.   When  enabled, debugging messages	will be	printed	to the
	      system console.

       log_all when set	it changes the behaviour of "log body" to log the  en-
	      tire packet rather than just the first 128 bytes.

       log_size	sets the size of the in-kernel log buffer in bytes.

       log_suppress  when  set,	IPFilter will check to see if the packet it is
	      logging is similar to the	one it previously logged  and  if  so,
	      increases	 the  occurance	 count for that	packet.	The previously
	      logged packet must not have yet been read	by ipmon(8).

       min_ttl is used to set the TTL value that packets below will be	marked
	      with the low-ttl attribute.

       nat_doflush  if	set it will cause the NAT code to do a more aggressive
	      flush of the NAT table at	the next opportunity. Once  the	 flush
	      has been done, the value is reset	to 0.

       nat_lock	this should only be changed using ipfs(8)

       nat_logging when	set, NAT will create log records that can be read from
	      /dev/ipnat.

       nat_maxbucket maximum number of entries allowed to exist	 in  each  NAT
	      hash  bucket.   This  prevents an	attacker trying	to load	up the
	      hash table with entries in a  single  bucket,  reducing  perfor-
	      mance.

       nat_rules_size size of the hash table to	store map rules.

       nat_table_max maximum number of entries allowed into the	NAT table

       nat_table_size size of the hash table used for NAT

       nat_table_wm_high  when	the  fill  percentage of the NAT table exceeds
	      this mark, more aggressive flushing is enabled.

       nat_table_wm_low	this sets the percentage  at  which  the  NAT  table's
	      agressive	flushing will turn itself off at.

       rdr_rules_size size of the hash table to	store rdr rules.

       state_lock this should only be changed using ipfs(8)

       state_logging  when set,	the stateful filtering will create log records
	      that can be read from /dev/ipstate.

       state_max maximum number	of entries allowed into	the state table

       state_maxbucket maximum number of entries  allowed  to  exist  in  each
	      state  hash bucket.  This	prevents an attacker trying to load up
	      the hash table with entries in a single bucket, reducing perfor-
	      mance.

       state_size size of the hash table used for stateful filtering

       state_wm_freq  this controls how	often the agressive flushing should be
	      run once the state table	exceeds	 state_wm_high	in  percentage
	      full.

       state_wm_high  when the fill percentage of the state table exceeds this
	      mark, more aggressive flushing is	enabled.

       state_wm_low this sets the percentage at	which the state	table's	agres-
	      sive flushing will turn itself off at.

       tcp_close_wait  timeout	used  when  a  TCP  state  entry  reaches  the
	      FIN_WAIT_2 state.

       tcp_closed timeout used when a TCP state	entry is ready to  be  removed
	      after either a RST packet	is seen.

       tcp_half_closed	timeout	 used  when  a	TCP  state  entry  reaches the
	      CLOSE_WAIT state.

       tcp_idle_timeout	timeout	used when a TCP	state entry reaches the	ESTAB-
	      LISHED state.

       tcp_last_ack  timeout  used  when  a  TCP  NAT/state  entry reaches the
	      LAST_ACK state.

       tcp_syn_received	timeout	applied	to a TCP NAT/state entry after SYN-ACK
	      packet has been seen.

       tcp_syn_sent  timeout applied to	a TCP NAT/state	entry after SYN	packet
	      has been seen.

       tcp_time_wait timeout used when	a  TCP	NAT/state  entry  reaches  the
	      TIME_WAIT	state.

       tcp_timeout  timeout used when a	TCP NAT/state entry reaches either the
	      half established state (one ack is seen after a SYN-ACK) or  one
	      side is in FIN_WAIT_1.

       udp_ack_timeout	default	 timeout  used	for UDP	NAT/state when a reply
	      packet is	seen for a UDP state that already exists

       udp_timeout default timeout used	for  UDP  NAT/state  when  the	packet
	      matches the rule

       update_ipid  when set, turns on changing	the IP id field	in NAT'd pack-
	      ets to a random number.

   Table of visible variables
       A list of all of	the tunables, their minimum, maximum and current  val-
       ues is as follows.

       Name		   Min	Max  Current
       active		   0	0    0
       chksrc		   0	1    0
       control_forwarding  0	1    0
       default_pass	   0	MAXUINT	  134217730
       ftp_debug	   0	10   0
       ftp_forcepasv	   0	1    1
       ftp_insecure	   0	1    0
       ftp_pasvonly	   0	1    0
       ftp_pasvrdr	   0	1    0
       ftp_single_xfer	   0	1    0
       hostmap_size	   1	MAXINT	  2047
       icmp_ack_timeout	   1	MAXINT	  12
       icmp_minfragmtu	   0	1    68
       icmp_timeout	   1	MAXINT	  120
       ip_timeout	   1	MAXINT	  120
       ipf_flags	   0	MAXUINT	  0
       ips_proxy_debug	   0	10   0
       log_all		   0	1    0
       log_size		   0	524288	  32768
       log_suppress	   0	1    1
       min_ttl		   0	1    4
       nat_doflush	   0	1    0
       nat_lock		   0	1    0
       nat_logging	   0	1    1
       nat_maxbucket	   1	MAXINT	  22
       nat_rules_size	   1	MAXINT	  127
       nat_table_max	   1	MAXINT	  30000
       nat_table_size	   1	MAXINT	  2047
       nat_table_wm_high   2	100  99
       nat_table_wm_low	   1	99   90
       rdr_rules_size	   1	MAXINT	  127
       state_lock	   0	1    0
       state_logging	   0	1    1
       state_max	   1	MAXINT	  4013
       state_maxbucket	   1	MAXINT	  26
       state_size	   1	MAXINT	  5737
       state_wm_freq	   2	999999	  20
       state_wm_high	   2	100  99
       state_wm_low	   1	99   90
       tcp_close_wait	   1	MAXINT	  480
       tcp_closed	   1	MAXINT	  60
       tcp_half_closed	   1	MAXINT	  14400
       tcp_idle_timeout	   1	MAXINT	  864000
       tcp_last_ack	   1	MAXINT	  60
       tcp_syn_received	   1	MAXINT	  480
       tcp_syn_sent	   1	MAXINT	  480
       tcp_time_wait	   1	MAXINT	  480
       tcp_timeout	   1	MAXINT	  480
       udp_ack_timeout	   1	MAXINT	  24
       udp_timeout	   1	MAXINT	  240
       update_ipid	   0	1    0

Calling	out to internal	functions
       IPFilter	 provides  a  pair of functions	that can be called from	a rule
       that allow for a	single rule to jump out	to a group  rather  than  walk
       through	a list of rules	to find	the group. If you've got multiple net-
       works, each with	its own	group of rules,	this feature may help  provide
       better filtering	performance.

       The  lookup  to	find which rule	group to jump to is done on either the
       source address or the destination address but not both.

       In this example below, we are blocking all packets by default but  then
       doing  a	lookup on the source address from group	1010. The two rules in
       the ipf.conf section are	lone members of	their group. For  an  incoming
       packet  that  is	 from 1.1.1.1, it will go through three	rules: (1) the
       block rule, (2) the call	rule and (3) the pass  rule  for  group	 1020.
       For a packet that is from 3.3.2.2, it will also go through three	rules:
       (1) the block rule, (2) the call	rule and (3) the pass rule  for	 group
       1030.  Should  a	 packet	 from 3.1.1.1 arrive, it will be blocked as it
       does not	match any of the entries in group 1010,	 leaving  it  to  only
       match the first rule.

       from ipf.conf
       -------------
       block in	all
       call now	srcgrpmap/1010 in all
       pass in proto tcp from any to any port =	80 group 1020
       pass in proto icmp all icmp-type	echo group 1030

       from ippool.conf
       ----------------
       group-map in role=ipf number=1010
	   { 1.1.1.1 group = 1020, 3.3.0.0/16 group = 1030; };

   IPFilter matching expressions
       An  experimental	 feature that has been added to	filter rules is	to use
       the same	expression matching that is available with various commands to
       flush  and  list	state/NAT table	entries. The use of such an expression
       precludes the filter rule from using the	normal IP header matching.

       pass in exp { "tcp.sport	23 or tcp.sport	50" } keep state

   Filter rules	with BPF
       On platforms that have the BPF built into the kernel, IPFilter  can  be
       built  to allow BPF expressions in filter rules.	This allows for	packet
       matching	to be on arbitrary data	in the packt. The use of a BPF expres-
       sion  replaces all of the other protocol	header matching	done by	IPFil-
       ter.

       pass in bpf-v4 {	"tcp and (src port 23 or src port 50)" } \
	   keep	state

       These rules tend	to be write-only because the act of compiling the fil-
       ter  expression	into  the  BPF instructions loaded into	the kernel can
       make it difficut	to accurately reconstruct the  original	 text  filter.
       The  end	 result	 is  that while	ipf.conf() can be easy to read,	under-
       standing	the output from	ipfstat	might not be.

VARIABLES
       This configuration file,	like all others	used with  IPFilter,  supports
       the use of variable substitution	throughout the text.

       nif="ppp0";
       pass in on $nif from any	to any

       would become

       pass in on ppp0 from any	to any

       Variables  can  be used recursively, such as 'foo="$bar baz";', so long
       as $bar exists when the parser reaches the assignment for foo.

       See ipf(8) for instructions on how to define variables to be used  from
       a shell environment.

FILES
       /dev/ipf	/etc/ipf.conf
       /usr/share/examples/ipfilter  Directory with examples.

SEE ALSO
       ipf(8), ipfstat(8), ippool.conf(5), ippool(8)

									IPF(5)

Want to link to this manual page? Use this URL:
<https://www.freebsd.org/cgi/man.cgi?query=ipf&sektion=5&manpath=FreeBSD+13.1-RELEASE+and+Ports>

Which of the following is the most common format for IP addresses?

Is a common TCP IP application layer protocol that is used for email transmission?

Which of the following TCP IP application layer protocols is used?

Which of the following TCP IP application layer protocols is used to move files over?