Source Tracking, State table sync in OpenBSD PF

Freebird

Ryan McBride has added two new features into PF's code - source tracking support and state table synchronization between two boxes running PF. The initial support for pf state synchronization over the network has been implemented as an in-kernel multicast IP protocol. Thanks roadr for the news story.

[Read email]
--------------------------------------

From: Ryan Thomas McBride <mcbride@cvs.openbsd.org>
To: source-changes@cvs.openbsd.org
Subject: CVS: cvs.openbsd.org: src
Date: Mon, 15 Dec 2003 07:12:26 GMT


CVSROOT: /cvs
Module name: src
Changes by: mcbride@cvs.openbsd.org 2003/12/15 00:11:31

Modified files:
sbin/ifconfig : ifconfig.c
sbin/pfctl : parse.y pf_print_state.c pfctl.c pfctl_parser.c
pfctl_parser.h
sys/net : if_pfsync.c if_pfsync.h pf.c pf_ioctl.c pfvar.h
sys/netinet : in.h in_proto.c
usr.bin/netstat: inet.c main.c netstat.h
usr.sbin/authpf: authpf.c
usr.sbin/tcpdump: interface.h print-ip.c print-pfsync.c

Log message:
Add initial support for pf state synchronization over the network.
Implemented as an in-kernel multicast IP protocol.

Turn it on like this:

# ifconfig pfsync0 up syncif fxp0

There is not yet any authentication on this protocol, so the syncif
must be on a trusted network. ie, a crossover cable between the two
firewalls.

NOTABLE CHANGES:
- A new index based on a unique (creatorid, stateid) tuple has been
added to the state tree.
- Updates now appear on the pfsync(4) interface; multiple updates may
be compressed into a single update.
- Applications which use bpf on pfsync(4) will need modification;
packets on pfsync no longer contains regular pf_state structs,
but pfsync_state structs which contain no pointers.

Much more to come.

=====================

From: mcbride@openbsd.org (Ryan McBride)
Subject: Source Tracking in PF
Date: 14 Dec 2003 16:46:17 -0800

I just committed code which adds support to track stateful connections
by source IP address. This allows a user to:
- Ensure that clients get a consistent IP mapping with load-balanced
translation/routing rules
- Limit the number of simultaneous connections a client can make
- Limit the number of clients which can connect through a rule

As always, the more people who test this and provide feedback, the
happier I am. Read below for details.

-Ryan



SYNTAX:

The 'sticky-address' keyword applies to translation rules; the
translation address will be selected from the list, but once a client
makes a connection, all subsequent connections are translated the same
way.

nat on $ext_if from $int_net to any -> \
{ 10.1.2.1, 10.1.2.3 } round-robin sticky-address

Similarly in the following case, connections to a server are mapped
randomly, but all connections from a client are mapped the same way.

rdr on $ext_if from any to $ext_if -> \
{ 192.168.0.4/30 } random sticky-address


In the case of tracking states per rule, the syntax is slightly
different. The 'source-track' state option is used to enable tracking,
limits can also be set there: 'max-src-states' limits how many states
from a single source can exist simultaneously and 'max-src-nodes'
limits how many source nodes can exist (effectively this is a limit
on how many clients can connect at once).

The following rule allows a maximum of 1000 source ip's to connect to a
webserver, each with a maximum of 3 simultaneous states:

pass in on $ext_if proto tcp to $webserver port www flags S/SA \
keep state (source-track, max-src-states 3, max-src-nodes 10)


By default, the source node is removed when all the states which
reference it are removed. However the timeout 'src.track' regulates
how long the source node is retained after all it's states have died.

set timeout src.track 900

A list of src nodes can be retrived with pfctl -sS, pfctl -vsS;
pfctl -vsi provides statistics on src-node useage (similar to the
statistics provided for states)