mirror of
https://git.FreeBSD.org/src.git
synced 2024-11-21 07:15:49 +00:00
manuals: fix "PP after SS | SH" warnings
The full mandoc warnings were:
skipping paragraph macro: PP after SS
skipping paragraph macro: PP after SH
The rendered output (in ascii and html) is not affected by this commit.
Fixes made by script in https://github.com/Tarsnap/freebsd-doc-scripts
Signed-off-by: Graham Percival <gperciva@tarsnap.com>
Reviewed by: jlduran, mhorne
MFC after: 1 week
Sponsored by: Tarsnap Backup Inc.
Pull Request: https://github.com/freebsd/freebsd-src/pull/1524
This commit is contained in:
Graham Percival
Mitchell Horne
parent
bc919e81e0
commit
e413da1358
@ -6,7 +6,6 @@ ipf \- packet filtering kernel interface
|
||||
.br
|
||||
#include <netinet/ip_fil.h>
|
||||
.SH IOCTLS
|
||||
.PP
|
||||
To add and delete rules to the filter list, three 'basic' ioctls are provided
|
||||
for use. The ioctl's are called as:
|
||||
.LP
|
||||
|
||||
@ -2,7 +2,6 @@
|
||||
.SH NAME
|
||||
ipf, ipf.conf \- IPFilter firewall rules file format
|
||||
.SH DESCRIPTION
|
||||
.PP
|
||||
The ipf.conf file is used to specify rules for the firewall, packet
|
||||
authentication and packet accounting components of IPFilter. To load rules
|
||||
specified in the ipf.conf file, the ipf(8) program is used.
|
||||
@ -29,7 +28,6 @@ the direction of the packet (in or out)
|
||||
address patterns or "all" to match any address information
|
||||
.RE
|
||||
.SS Long lines
|
||||
.PP
|
||||
For rules lines that are particularly long, it is possible to split
|
||||
them over multiple lines implicitly like this:
|
||||
.PP
|
||||
@ -45,7 +43,6 @@ pass in on bgeo proto tcp from 1.1.1.1 port > 1000 \\
|
||||
to 2.2.2.2 port < 5000 flags S keep state
|
||||
.fi
|
||||
.SS Comments
|
||||
.PP
|
||||
Comments in the ipf.conf file are indicated by the use of the '#' character.
|
||||
This can either be at the start of the line, like this:
|
||||
.PP
|
||||
@ -60,7 +57,6 @@ Or at the end of a like, like this:
|
||||
pass in proto icmp from any to any # Allow all ICMP packets in
|
||||
.fi
|
||||
.SH Firewall rules
|
||||
.PP
|
||||
This section goes into detail on how to construct firewall rules that
|
||||
are placed in the ipf.conf file.
|
||||
.PP
|
||||
@ -69,7 +65,6 @@ 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.
|
||||
.SS Filter rule keywords
|
||||
.PP
|
||||
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
|
||||
@ -131,7 +126,6 @@ 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.
|
||||
.SS Matching Network Interfaces
|
||||
.PP
|
||||
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
|
||||
@ -158,7 +152,6 @@ block in on bge0 all
|
||||
pass out on bge0 all
|
||||
.fi
|
||||
.SS Address matching (basic)
|
||||
.PP
|
||||
The first and most basic part of matching for filtering rules is to
|
||||
specify IP addresses and TCP/UDP port numbers. The source address
|
||||
information is matched by the "from" information in a filter rule
|
||||
@ -197,7 +190,6 @@ is processing that part of the configuration file, leading to long
|
||||
delays, if not errors, in loading the filter rules.
|
||||
.RE
|
||||
.SS Protocol Matching
|
||||
.PP
|
||||
To match packets based on TCP/UDP port information, it is first necessary
|
||||
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
|
||||
@ -209,7 +201,6 @@ block out proto udp from any to 10.1.1.1
|
||||
pass in proto icmp from any to 192.168.0.0/16
|
||||
.fi
|
||||
.SS Sending back error packets
|
||||
.PP
|
||||
When a packet is just discarded using a block rule, there is no feedback 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
|
||||
@ -317,7 +308,6 @@ block return-icmp-as-dest(port-unr) in proto udp \\
|
||||
from any to 192.168.1.0/24
|
||||
.fi
|
||||
.SS TCP/UDP Port Matching
|
||||
.PP
|
||||
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
|
||||
@ -361,7 +351,6 @@ If there is no desire to mention any specific source or destintion
|
||||
information in a filter rule then the word "all" can be used to
|
||||
indicate that all addresses are considered to match the rule.
|
||||
.SS IPv4 or IPv6
|
||||
.PP
|
||||
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
|
||||
@ -399,13 +388,11 @@ protocol family qualifier:
|
||||
pass in family inet6 proto udp from any to any port = 53
|
||||
.fi
|
||||
.SS First match vs last match
|
||||
.PP
|
||||
To change the default behaviour from being the last matched rule decides
|
||||
the outcome to being the first matched rule, the word "quick" is inserted
|
||||
to the rule.
|
||||
.SH Extended Packet Matching
|
||||
.SS Beyond using plain addresses
|
||||
.PP
|
||||
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
|
||||
@ -475,7 +462,6 @@ with.
|
||||
pass in proto icmp from any to (bge0)/32
|
||||
.fi
|
||||
.SS Using address pools
|
||||
.PP
|
||||
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
|
||||
@ -505,7 +491,6 @@ There are different operational characteristics with each, so there
|
||||
may be some situations where a pool works better than hash and vice
|
||||
versa.
|
||||
.SS Matching TCP flags
|
||||
.PP
|
||||
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
|
||||
@ -562,7 +547,6 @@ 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.
|
||||
.SS Matching on ICMP header information
|
||||
.PP
|
||||
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
|
||||
@ -627,7 +611,6 @@ unreach (unreachable,
|
||||
whoreq (WRU request),
|
||||
whorep (WRU reply).
|
||||
.SH Stateful Packet Filtering
|
||||
.PP
|
||||
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.
|
||||
@ -694,7 +677,6 @@ 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.
|
||||
.SS Stateful filtering options
|
||||
.PP
|
||||
The following options can be used with stateful filtering:
|
||||
.HP
|
||||
limit
|
||||
@ -812,7 +794,6 @@ If there is no IP protocol implied by addresses or other features of
|
||||
the rule, IPFilter will assume that no netmask is an all ones netmask
|
||||
for both IPv4 and IPv6.
|
||||
.SS Tieing down a connection
|
||||
.PP
|
||||
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:
|
||||
@ -851,7 +832,6 @@ pass in on bge0,bge1 out-via bge1,bge0 proto tcp \\
|
||||
from any to any port = 22 flags S keep state
|
||||
.fi
|
||||
.SS Working with packet fragments
|
||||
.PP
|
||||
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.
|
||||
.PP
|
||||
@ -883,7 +863,6 @@ An example of how this is done is as follows:
|
||||
pass in proto udp from any port = 2049 to any with frags keep frags
|
||||
.fi
|
||||
.SH Building a tree of rules
|
||||
.PP
|
||||
Writing your filter rules as one long list of rules can be both inefficient
|
||||
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.
|
||||
@ -947,7 +926,6 @@ 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
|
||||
.fi
|
||||
.SS Decapsulation
|
||||
.PP
|
||||
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 adjust its view of the
|
||||
@ -982,7 +960,6 @@ 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.
|
||||
.SS Policy Based Routing
|
||||
.PP
|
||||
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
|
||||
@ -1034,7 +1011,6 @@ pass in on bge0 to bge1:1.1.1.1 reply-to hme1:2.1.1.2 \\
|
||||
to any port = 80 flags S keep state
|
||||
.fi
|
||||
.SS Matching IPv4 options
|
||||
.PP
|
||||
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 used to store IP options. These options are
|
||||
@ -1115,7 +1091,6 @@ ump (Upstream Multicast Packet),
|
||||
visa (Experimental Access Control)
|
||||
and zsu (Experimental Measurement).
|
||||
.SS Security with CIPSO and IPSO
|
||||
.PP
|
||||
IPFilter supports filtering on IPv4 packets using security attributes embedded
|
||||
in the IP options part of the packet. These options are usually only used on
|
||||
networks and systems that are using lablled security. Unless you know that
|
||||
@ -1139,7 +1114,6 @@ block in quick all with opt sec-class unclass
|
||||
pass in all with opt sec-class secret
|
||||
.fi
|
||||
.SS Matching IPv6 extension headers
|
||||
.PP
|
||||
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.
|
||||
@ -1153,7 +1127,6 @@ mobility (IP mobility),
|
||||
none,
|
||||
routing.
|
||||
.SS Logging
|
||||
.PP
|
||||
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
|
||||
@ -1211,7 +1184,6 @@ pass in log level local1.info proto tcp \\
|
||||
ipfstat(8) reports how many packets have been successfully logged and how
|
||||
many failed attempts to log a packet there were.
|
||||
.SS Filter rule comments
|
||||
.PP
|
||||
If there is a desire to associate a text string, be it an administrative
|
||||
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
|
||||
@ -1224,7 +1196,6 @@ pass out quick proto tcp from any port = 80 \\
|
||||
to any comment "all web server traffic is ok"
|
||||
.fi
|
||||
.SS Tags
|
||||
.PP
|
||||
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
|
||||
@ -1249,7 +1220,6 @@ such as grep, extracting log records of interest is simplified.
|
||||
block in quick log ... set-tag(log=33)
|
||||
.fi
|
||||
.SH Filter Rule Expiration
|
||||
.PP
|
||||
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
|
||||
@ -1264,7 +1234,6 @@ pass in on fxp0 proto tcp from any \\
|
||||
to port = 22 flags S keep state rule-ttl 30
|
||||
.fi
|
||||
.SH Internal packet attributes
|
||||
.PP
|
||||
In addition to being able to filter on very specific network and transport
|
||||
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
|
||||
@ -1332,7 +1301,6 @@ block in all
|
||||
pass in all with not bad
|
||||
.fi
|
||||
.SH Tuning IPFilter
|
||||
.PP
|
||||
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
|
||||
@ -1543,7 +1511,6 @@ update_ipid
|
||||
when set, turns on changing the IP id field in NAT'd packets to a random
|
||||
number.
|
||||
.SS Table of visible variables
|
||||
.PP
|
||||
A list of all of the tunables, their minimum, maximum and current
|
||||
values is as follows.
|
||||
.PP
|
||||
@ -1602,7 +1569,6 @@ udp_timeout 1 MAXINT 240
|
||||
update_ipid 0 1 0
|
||||
.fi
|
||||
.SH Calling out to internal functions
|
||||
.PP
|
||||
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
|
||||
@ -1637,7 +1603,6 @@ group-map in role=ipf number=1010
|
||||
{ 1.1.1.1 group = 1020, 3.3.0.0/16 group = 1030; };
|
||||
.fi
|
||||
.SS IPFilter matching expressions
|
||||
.PP
|
||||
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
|
||||
@ -1647,7 +1612,6 @@ precludes the filter rule from using the normal IP header matching.
|
||||
pass in exp { "tcp.sport 23 or tcp.sport 50" } keep state
|
||||
.fi
|
||||
.SS Filter rules with BPF
|
||||
.PP
|
||||
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 expression
|
||||
@ -1665,7 +1629,6 @@ accurately reconstruct the original text filter. The end result is that
|
||||
while ipf.conf() can be easy to read, understanding the output from
|
||||
ipfstat might not be.
|
||||
.SH VARIABLES
|
||||
.PP
|
||||
This configuration file, like all others used with IPFilter, supports the
|
||||
use of variable substitution throughout the text.
|
||||
.PP
|
||||
|
||||
@ -22,7 +22,6 @@ ipf \- alters packet filtering lists for IP packet input and output
|
||||
<\fIfilename\fP>
|
||||
[...]]
|
||||
.SH DESCRIPTION
|
||||
.PP
|
||||
\fBipf\fP opens the filenames listed (treating "\-" as stdin) and parses the
|
||||
file for a set of rules which are to be added or removed from the packet
|
||||
filter rule set.
|
||||
@ -176,9 +175,7 @@ IPF_PREDEFINED='my_server="10.1.1.1"; my_client="10.1.1.2";'
|
||||
.SH SEE ALSO
|
||||
ipftest(1), mkfilters(1), ipf(4), ipl(4), ipf(5), ipfstat(8), ipmon(8), ipnat(8)
|
||||
.SH DIAGNOSTICS
|
||||
.PP
|
||||
Needs to be run as root for the packet filtering lists to actually
|
||||
be affected inside the kernel.
|
||||
.SH BUGS
|
||||
.PP
|
||||
If you find any, please send email to me at darrenr@pobox.com
|
||||
|
||||
@ -2,7 +2,6 @@
|
||||
.SH NAME
|
||||
IP Filter
|
||||
.SH DESCRIPTION
|
||||
.PP
|
||||
IP Filter is a package providing packet filtering capabilities for a variety
|
||||
of operating systems. On a properly setup system, it can be used to build a
|
||||
firewall.
|
||||
|
||||
@ -40,7 +40,6 @@ ipfs \- saves and restores information for NAT and state tables.
|
||||
.B \-i
|
||||
<if1>,<if2>
|
||||
.SH DESCRIPTION
|
||||
.PP
|
||||
\fBipfs\fP allows state information created for NAT entries and rules using
|
||||
\fIkeep state\fP to be locked (modification prevented) and then saved to disk,
|
||||
allowing for the system to experience a reboot, followed by the restoration
|
||||
@ -117,10 +116,8 @@ operation and unlocked once complete.
|
||||
.SH SEE ALSO
|
||||
ipf(8), ipl(4), ipmon(8), ipnat(8)
|
||||
.SH DIAGNOSTICS
|
||||
.PP
|
||||
Perhaps the -W and -R operations should set the locking but rather than
|
||||
undo it, restore it to what it was previously. Fragment table information
|
||||
is currently not saved.
|
||||
.SH BUGS
|
||||
.PP
|
||||
If you find any, please send email to me at darrenr@pobox.com
|
||||
|
||||
@ -34,7 +34,6 @@ interface
|
||||
<optionlist>
|
||||
]
|
||||
.SH DESCRIPTION
|
||||
.PP
|
||||
\fBipftest\fP is provided for the purpose of being able to test a set of
|
||||
filter rules without having to put them in place, in operation and proceed
|
||||
to test their effectiveness. The hope is that this minimises disruptions
|
||||
|
||||
@ -52,7 +52,6 @@ The lines above would save all ipf log entries to /var/log/ipf-log, send
|
||||
all of the entries for NAT (ipnat related) to syslog and generate an email
|
||||
to root for each log entry from the state tables.
|
||||
.SH SYNTAX - MATCHING
|
||||
.PP
|
||||
In the above example, the matching segment was confined to matching on
|
||||
the type of log entry generated. The full list of fields that can be
|
||||
used here is:
|
||||
@ -189,7 +188,6 @@ it can then be used in any
|
||||
.I do
|
||||
statement.
|
||||
.SH EXAMPLES
|
||||
.PP
|
||||
Some further examples are:
|
||||
.nf
|
||||
|
||||
@ -208,7 +206,6 @@ match { dstip 127.0.0.1; } do { local("local options"); };
|
||||
#
|
||||
.fi
|
||||
.SH MATCHING
|
||||
.PP
|
||||
All entries of the rules present in the file are
|
||||
compared for matches - there is no first or last rule match.
|
||||
.SH FILES
|
||||
|
||||
@ -27,7 +27,6 @@ ipmon \- monitors /dev/ipl for logged packets
|
||||
.B <filename>
|
||||
]
|
||||
.SH DESCRIPTION
|
||||
.LP
|
||||
\fBipmon\fP opens \fB/dev/ipl\fP for reading and awaits data to be saved from
|
||||
the packet filter. The binary data read from the device is reprinted in
|
||||
human readable form, however, IP#'s are not mapped back to hostnames, nor are
|
||||
@ -191,5 +190,4 @@ recorded data.
|
||||
.SH SEE ALSO
|
||||
ipl(4), ipmon(5), ipf(8), ipfstat(8), ipnat(8)
|
||||
.SH BUGS
|
||||
.PP
|
||||
If you find any, please send email to me at darrenr@pobox.com
|
||||
|
||||
@ -8,7 +8,6 @@ ipnat \- user interface to the NAT
|
||||
]
|
||||
.B \-f <\fIfilename\fP>
|
||||
.SH DESCRIPTION
|
||||
.PP
|
||||
\fBipnat\fP opens the filename given (treating "\-" as stdin) and parses the
|
||||
file for a set of rules which are to be added or removed from the IP NAT.
|
||||
.PP
|
||||
|
||||
@ -10,7 +10,6 @@ ipnat \- Network Address Translation kernel interface
|
||||
.br
|
||||
#include <netinet/ip_nat.h>
|
||||
.SH IOCTLS
|
||||
.PP
|
||||
To add and delete rules to the NAT list, two 'basic' ioctls are provided
|
||||
for use. The ioctl's are called as:
|
||||
.LP
|
||||
|
||||
@ -3,7 +3,6 @@
|
||||
.SH NAME
|
||||
ipnat, ipnat.conf \- IPFilter NAT file format
|
||||
.SH DESCRIPTION
|
||||
.PP
|
||||
The
|
||||
.B ipnat.conf
|
||||
file is used to specify rules for the Network Address Translation (NAT)
|
||||
@ -30,7 +29,6 @@ to text that appears before the "->" and the "right hand side" (RHS) for text
|
||||
that appears after it. In essence, the LHS is the packet matching and the
|
||||
RHS is the new data to be used.
|
||||
.SH VARIABLES
|
||||
.PP
|
||||
This configuration file, like all others used with IPFilter, supports the
|
||||
use of variable substitution throughout the text.
|
||||
.nf
|
||||
@ -280,7 +278,6 @@ of (say) 172.192.0.2 wanted 260 simultaneous connections going out, they would
|
||||
be limited to 252 with \fBmap-block\fP but would just \fImove on\fP to the next
|
||||
IP address with the \fBmap\fP command.
|
||||
.SS Extended matching
|
||||
.PP
|
||||
If it is desirable to match on both the source and destination of a packet
|
||||
before applying an address translation to it, this can be achieved by using
|
||||
the same from-to syntax as is used in \fBipf.conf\fP(5). What follows
|
||||
@ -322,7 +319,6 @@ the defined pool only has /24's or /32's. Pools may also be used
|
||||
.I wherever
|
||||
the from-to syntax in \fBipnat.conf\fR(5) is allowed.
|
||||
.SH INBOUND DESTINATION TRANSLATION (redirection)
|
||||
.PP
|
||||
Redirection of packets is used to change the destination fields in a packet
|
||||
and is supported for packets that are moving \fIin\fP on a network interface.
|
||||
While the same general syntax for
|
||||
@ -465,7 +461,6 @@ rdr le0,ppp0 9.8.7.6/32 port 80 -> 1.1.1.1,1.1.1.2 port 80 tcp
|
||||
round-robin frag age 40/40 sticky mssclamp 1000 tag tagged
|
||||
.fi
|
||||
.SH REWRITING SOURCE AND DESTINATION
|
||||
.PP
|
||||
Whilst the above two commands provide a lot of flexibility in changing
|
||||
addressing fields in packets, often it can be of benefit to translate
|
||||
\fIboth\fP source \fBand\fR destination at the same time or to change
|
||||
@ -549,7 +544,6 @@ rewrite from any to any port = 80 ->
|
||||
src 1.1.2.3 - 1.1.2.6 dst 2.2.3.4 - 2.2.3.6;
|
||||
.fi
|
||||
.SH DIVERTING PACKETS
|
||||
.PP
|
||||
If you'd like to send packets to a UDP socket rather than just another
|
||||
computer to be decapsulated, this can be achieved using a
|
||||
.B divert
|
||||
@ -598,7 +592,6 @@ are flushed out, it is expected that the operator will similarly
|
||||
flush the NAT table and thus NAT sessions are not removed when the
|
||||
NAT rules are flushed out.
|
||||
.SH RULE ORDERING
|
||||
.PP
|
||||
.B NOTE:
|
||||
Rules in
|
||||
.B ipnat.conf
|
||||
@ -655,7 +648,6 @@ rdr le0 from 1.1.1.0/24 to 192.2.2.1 port 80 -> 127.0.0.1 3128 tcp
|
||||
.PP
|
||||
Then no packets will match the 2nd rule, they'll all match the first.
|
||||
.SH IPv6
|
||||
.PP
|
||||
In all of the examples above, where an IPv4 address is present, an IPv6
|
||||
address can also be used. All rules must use either IPv4 addresses with
|
||||
both halves of the NAT rule or IPv6 addresses for both halves. Mixing
|
||||
@ -667,7 +659,6 @@ For shorthand notations such as "0/32", the equivalent for IPv6 is
|
||||
implicit direction that the address should be IPv6, not IPv4.
|
||||
To be unambiguous with 0/0, for IPv6 use ::0/0.
|
||||
.SH KERNEL PROXIES
|
||||
.PP
|
||||
IP Filter comes with a few, simple, proxies built into the code that is loaded
|
||||
into the kernel to allow secondary channels to be opened without forcing the
|
||||
packets through a user program. The current state of the proxies is listed
|
||||
|
||||
@ -15,7 +15,6 @@ ipnat \- user interface to the NAT subsystem
|
||||
]
|
||||
.B \-f <\fIfilename\fP>
|
||||
.SH DESCRIPTION
|
||||
.PP
|
||||
\fBipnat\fP opens the filename given (treating "\-" as stdin) and parses the
|
||||
file for a set of rules which are to be added or removed from the IP NAT.
|
||||
.PP
|
||||
|
||||
@ -38,7 +38,6 @@ heirarchical matching, so it is possible to define a subnet as matching
|
||||
but then exclude specific addresses from it.
|
||||
.SS
|
||||
Evolving Configuration
|
||||
.PP
|
||||
Over time the configuration syntax used by ippool.conf(5) has evolved.
|
||||
Originally the syntax used was more verbose about what a particular
|
||||
value was being used for, for example:
|
||||
@ -65,7 +64,6 @@ configuration syntax and all output using "ippool -l" will also be in the
|
||||
new configuration syntax.
|
||||
.SS
|
||||
IPFilter devices and pools
|
||||
.PP
|
||||
To cater to different administration styles, ipool.conf(5) allows you to
|
||||
tie a pool to a specific role in IPFilter. The recognised role names are:
|
||||
.HP
|
||||
@ -89,7 +87,6 @@ all
|
||||
pools that are defined for the "all" role are available to all types of
|
||||
rules, be they NAT rules in ipnat.conf(5) or firewall rules in ipf.conf(5).
|
||||
.SH Address Pools
|
||||
.PP
|
||||
An address pool can be used in ipf.conf(5) and ipnat.conf(5) for matching
|
||||
the source or destination address of packets. They can be referred to either
|
||||
by name or number and can hold an arbitrary number of address patterns to
|
||||
@ -163,7 +160,6 @@ block in from pool/microsoft to any
|
||||
Note that there are limitations on the output returned by whois servers
|
||||
so be aware that their output may not be 100% perfect for your goal.
|
||||
.SH Destination Lists
|
||||
.PP
|
||||
Destination lists are provided for use primarily with NAT redirect rules
|
||||
(rdr). Their purpose is to allow more sophisticated methods of selecting
|
||||
which host to send traffic to next than the simple round-robin technique
|
||||
@ -242,7 +238,6 @@ pool all/dstlist (name servers; policy weighted connection;)
|
||||
{ bge0:1.1.1.2; bge0:1.1.1.4; bge1:1.1.1.5; bge1:1.1.1.9; };
|
||||
.fi
|
||||
.SH Group maps
|
||||
.PP
|
||||
Group maps are provided to allow more efficient processing of packets
|
||||
where there are a larger number of subnets and groups of rules for those
|
||||
subnets. Group maps are used with "call" rules in ipf.conf(5) that
|
||||
@ -282,7 +277,6 @@ The limitation with group maps is that only the source address or the
|
||||
destination address can be used to map the packet to the starting group,
|
||||
not both, in your ipf.conf(5) file.
|
||||
.SH Hash Tables
|
||||
.PP
|
||||
The hash table is operationally similar to the address pool. It is
|
||||
used as a store for a collection of address to match on, saving the
|
||||
need to write a lengthy list of rules. As with address pools, searching
|
||||
|
||||
@ -28,7 +28,6 @@ ippool \- user interface to the IPFilter pools
|
||||
.B ippool
|
||||
-s [-dtv]
|
||||
.SH DESCRIPTION
|
||||
.PP
|
||||
.B Ippool
|
||||
is used to manage information stored in the IP pools subsystem of IPFilter.
|
||||
Configuration file information may be parsed and loaded into the kernel,
|
||||
|
||||
@ -3,7 +3,6 @@
|
||||
.SH NAME
|
||||
ipscan, ipscan.conf \- ipscan file format
|
||||
.SH DESCRIPTION
|
||||
.PP
|
||||
WARNING: This feature is to be considered experimental and may change
|
||||
significantly until a final implementation is drawn up.
|
||||
.PP
|
||||
|
||||
@ -10,7 +10,6 @@ ipscan \- user interface to the IPFilter content scanning
|
||||
]
|
||||
.B \-f <\fIfilename\fP>
|
||||
.SH DESCRIPTION
|
||||
.PP
|
||||
\fBipscan\fP opens the filename given (treating "\-" as stdin) and parses the
|
||||
file to build up a content scanning configuration to load into the kernel.
|
||||
Currently only the first 16 bytes of a connection can be compared.
|
||||
|
||||
@ -20,7 +20,6 @@ ipresend \- resend IP packets out to network
|
||||
<\fIfilename\fP>
|
||||
]
|
||||
.SH DESCRIPTION
|
||||
.PP
|
||||
\fBipresend\fP was designed to allow packets to be resent, once captured,
|
||||
back out onto the network for use in testing. \fIipresend\fP supports a
|
||||
number of different file formats as input, including saved snoop/tcpdump
|
||||
@ -97,10 +96,8 @@ The input file is composed of text descriptions of IP packets.
|
||||
.SH SEE ALSO
|
||||
snoop(1m), tcpdump(8), etherfind(8c), ipftest(1), ipresend(1), iptest(1), bpf(4), dlpi(7p)
|
||||
.SH DIAGNOSTICS
|
||||
.PP
|
||||
Needs to be run as root.
|
||||
.SH BUGS
|
||||
.PP
|
||||
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.
|
||||
If you find any, please send email to me at darrenr@pobox.com
|
||||
|
||||
@ -35,7 +35,6 @@ ipsend \- sends IP packets
|
||||
<\fIwindow\fP>
|
||||
] <destination> [TCP-flags]
|
||||
.SH DESCRIPTION
|
||||
.PP
|
||||
\fBipsend\fP can be compiled in two ways. The first is used to send one-off
|
||||
packets to a destination host, using command line options to specify various
|
||||
attributes present in the headers. The \fIdestination\fP must be given as
|
||||
@ -103,8 +102,6 @@ enable verbose mode.
|
||||
.SH SEE ALSO
|
||||
ipsend(1), ipresend(1), iptest(1), protocols(4), bpf(4), dlpi(7p)
|
||||
.SH DIAGNOSTICS
|
||||
.PP
|
||||
Needs to be run as root.
|
||||
.SH BUGS
|
||||
.PP
|
||||
If you find any, please send email to me at darrenr@pobox.com
|
||||
|
||||
@ -7,7 +7,6 @@ text file which fits the grammar described below. The purpose of this
|
||||
grammar is to allow IP packets to be described in an arbitary way which
|
||||
also allows encapsulation to be so done to an arbitary level.
|
||||
.SH GRAMMAR
|
||||
.LP
|
||||
.nf
|
||||
line ::= iface | arp | send | defrouter | ipv4line .
|
||||
|
||||
@ -80,7 +79,6 @@ databodyopts ::= "len" number | "value" string | "file" filename .
|
||||
icmpechoopts ::= "icmpseq" number | "icmpid" number .
|
||||
.fi
|
||||
.SH COMMANDS
|
||||
.PP
|
||||
Before sending any packets or defining any packets, it is necessary to
|
||||
describe the interface(s) which will be used to send packets out.
|
||||
.TP
|
||||
|
||||
@ -23,7 +23,6 @@ iptest \- automatically generate a packets to test IP functionality
|
||||
<\fIsource\fP>
|
||||
] <destination>
|
||||
.SH DESCRIPTION
|
||||
.PP
|
||||
\fBiptest\fP ...
|
||||
.SH OPTIONS
|
||||
.TP
|
||||
@ -98,5 +97,4 @@ Only one of the numeric test options may be given when \fIiptest\fP is run.
|
||||
.PP
|
||||
Needs to be run as root.
|
||||
.SH BUGS
|
||||
.PP
|
||||
If you find any, please send email to me at darrenr@pobox.com
|
||||
|
||||
Loading…
Reference in New Issue
Block a user