pfsync(4)
NAME
pfsync - packet filter state table logging interface
SYNOPSIS
device pfsync
DESCRIPTION
- The pfsync interface is a pseudo-device which exposes cer
- tain changes to
the state table used by pf(4). If configured with a physi - cal synchronisation interface, pfsync will send state changes out on that
- interface
using IP multicast, and insert state changes received on - that interface
from other systems into the state table. - By default, all local changes to the state table are exposed
- via pfsync.
However, state changes from packets received by pfsync over - the network
are not rebroadcast. States created by a rule marked with - the no-sync
keyword are omitted from the pfsync interface (see - pf.conf(5) for
details). - The pfsync interface will attempt to collapse multiple up
- dates of the
same state into one message where possible. The maximum - number of times
this can be done before the update is sent out is controlled - by the
maxupd parameter to ifconfig (see ifconfig(8) and the exam - ple below for
more details). - Each packet retrieved on this interface has a header associ
- ated with it
of length PFSYNC_HDRLEN. The header indicates the version - of the protocol, address family, action taken on the following states,
- and the number
of state table entries attached in this packet. This struc - ture is
defined in <net/if_pfsync.h> as:
struct pfsync_header {u_int8_t version;
u_int8_t af;
u_int8_t action;
u_int8_t count;- };
NETWORK SYNCHRONISATION
- States can be synchronised between two or more firewalls us
- ing this
interface, by specifying a synchronisation interface using - ifconfig(8).
For example, the following command sets fxp0 as the synchro - nisation
interface:
# ifconfig pfsync0 syncdev fxp0- By default, state change messages are sent out on the syn
- chronisation
interface using IP multicast packets. The protocol is IP - protocol 240,
PFSYNC, and the multicast group used is 224.0.0.240. When a - peer address
is specified using the syncpeer keyword, the peer address is - used as a
destination for the pfsync traffic, and the traffic can then - be protected
using ipsec(4). In such a configuration, the syncdev should - be set to
the enc(4) interface, as this is where the traffic arrives - when it is
decapsulated, e.g.:
# ifconfig pfsync0 syncpeer 10.0.0.2 syncdev enc0- It is important that the pfsync traffic be well secured as
- there is no
authentication on the protocol and it would be trivial to - spoof packets
which create states, bypassing the pf ruleset. Either run - the pfsync
protocol on a trusted network - ideally a network dedicated - to pfsync
messages such as a crossover cable between two firewalls, or - specify a
peer address and protect the traffic with ipsec(4). - For pfsync to start its operation automatically at the sys
- tem boot time,
pfsync_enable and pfsync_syncdev variables should be used in - rc.conf(5).
It is not advisable to set up pfsync with common network in - terface configuration variables of rc.conf(5) because pfsync must start
- after its
syncdev, which cannot be always ensured in the latter case.
EXAMPLES
- pfsync and carp(4) can be used together to provide automatic
- failover of
a pair of firewalls configured in parallel. One firewall - handles all
traffic - if it dies or is shut down, the second firewall - takes over
automatically. - Both firewalls in this example have three sis(4) interfaces.
- sis0 is the
external interface, on the 10.0.0.0/24 subnet; sis1 is the - internal
interface, on the 192.168.0.0/24 subnet; and sis2 is the - pfsync interface, using the 192.168.254.0/24 subnet. A crossover cable
- connects the
two firewalls via their sis2 interfaces. On all three in - terfaces, firewall A uses the .254 address, while firewall B uses .253.
- The interfaces
are configured as follows (firewall A unless otherwise indi - cated):
- Interfaces configuration in /etc/rc.conf:
network_interfaces="lo0 sis0 sis1 sis2"
cloned_interfaces="carp0 carp1"
ifconfig_sis0="10.0.0.254/24"
ifconfig_sis1="192.168.0.254/24"
ifconfig_sis2="192.168.254.254/24"
ifconfig_carp0="vhid 1 pass foo 10.0.0.1/24"
ifconfig_carp1="vhid 2 pass bar 192.168.0.1/24"
pfsync_enable="YES"
pfsync_syncdev="sis2"- pf(4) must also be configured to allow pfsync and carp(4)
- traffic
through. The following should be added to the top of - /etc/pf.conf:
pass quick on { sis2 } proto pfsync
pass on { sis0 sis1 } proto carp keep state- If it is preferable that one firewall handle the traffic,
- the advskew on
the backup firewall's carp(4) interfaces should be set to - something
higher than the primary's. For example, if firewall B is - the backup, its
carp1 configuration would look like this:
ifconfig_carp1="vhid 2 pass bar advskew 100- 192.168.0.1/24"
- The following must also be added to /etc/sysctl.conf:
net.inet.carp.preempt=1
BUGS
- Possibility to view state changes using tcpdump(1) has not
- been ported
from OpenBSD yet.
SEE ALSO
- bpf(4), carp(4), ifconfig(8), inet(4), inet6(4), ipsec(4),
- netintro(4),
pf(4), pf.conf(5), protocols(5), rc.conf(5)
HISTORY
- The pfsync device first appeared in OpenBSD 3.3. The pfsync
- device was
imported to FreeBSD 5.3. - BSD February 23, 2005