OpenBSD Journal

PF state sync now in-tree

Contributed by jose on from the sync-sync-sync dept.

Peter Hessler writes:


"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.

ok deraadt@ "
Several people wrote about this, because this looks super cool.

(Comments are closed)


Comments
  1. By Anonymous Coward () on

    It looks like 3.5 will shape up to be a great platform for deploying redundant firewalls.

    I only wish all of these features were available in a stable release - I'm about to deploy such a setup in a few weeks and for now we'll have to go with a single wall.

  2. By panda () panda@NOSPAMepita.fr on mailto:panda@NOSPAMepita.fr

    ... And you get the functionnality of chkpt fw1 combined with the stability and flexibility of pf/OpenBSD, I'm really looking forward to 3.5 to see how it goes once it's 'released'.

    I'll try it out as soon as possible of of -current.

    Great job !

    Comments
    1. By djm () on

      ... And you get the functionnality of chkpt fw1

      To be fair to CheckPoint, their HA product (ClusterXL) does a fair bit more than failover and state sync - it can do some pretty neat load sharing by ARP advertising a multicast address shared between two or more firewall units as a unicast IP address. Somehow the units arbitrate which will (stickily) pick up a given connection.

      State-synchronised IPsec/isakmp SAs would be cool, but I think there are patents (Nokia IIRC) in this area.

      Comments
      1. By Matt Van Mater () on

        Don't the patents only apply to their particular implementation of this feature? Couldn't the dev team replicate this from scratch with no legal recourse?

        Isn't a similar technology to CARP found in Cisco products? I would think the same rules apply in both scenarios.

    2. By Dan () on

      I can not see how CARP can help here.

      SEGMENT_1
      .............................
      |1 |1
      +--------+ +---------+
      | | Sync | |
      | PF_A |.......| PF_B |
      | | | |
      +-.------+ +----.----+
      |2 |2
      ...:...................:.......
      SEGMENT_2

      let say you use CARP on ALL interfaces, and PF_A is the primery on both segments.

      let say interface 1 on PF_A fails. then all trafic from SEGMENT_A will use interface 1 of PF_B. CARP would take care of that.

      BUT what would happen to traffic from SEGMENT_B?
      Would it use PF_A or PF_B?
      If It will use interface 2 on PF_B then no problems. but if it will use interface 2 on PF_A, then the network would fail because interface 1 of PF_A is down.

      Because PF_A is the primery for SEGMENT_2, then the traffic would be routed via PF_A, and the network will fail.

      What is missing here is a method for CARP to track changes on other interfaces, so when interface 1 failes then shut down interface 2 as well, or to drop it's CARP priority.

      Dan

      Comments
      1. By Dan () on

        ............................. |1 |1 +--------+ +---------+ | | Sync | | | HOSTA |.......| HOSTB | | | | | +-.------+ +----.----+ |2 |2 ...:...................:.......

      2. By Dan () on

        ............................. |1 |1 +--------+ +---------+ | | Sync | | | HOSTA |.......| HOSTB | | | | | +-.------+ +----.----+ |2 |2 ...:...................:.......

      3. By Dan () on

        how to preserve white spaces??

        Comments
        1. By Fábio Olivé Leite () olive at unixforge.org on mailto:olive at unixforge.org

          When posting a comment select the HTML option and use the <pre> tag.

      4. By Test () on

        SEGMENT_1 ............................. |1 |1 +--------+ +---------+ | | Sync | | | PF_A |.......| PF_B | | | | | +-.------+ +----.----+ |2 |2 ...:...................:....... SEGMENT_2

      5. By lx () on

        I'm not familiar with CARP, but it sounds like you're needing what
        VRID dependencies/monitored circuits do in a good VRRP implementation.

        Comments
        1. By Anonymous Coward () on

          As I understand it, CARP is OpenBSD's free alternative to VRRP. I hope that it will be taken up by others who want that functionality.

Credits

Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original deadly.org with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]