Contributed by jose on from the sync-sync-sync dept.
"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)
By Anonymous Coward () on
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.
By panda () panda@NOSPAMepita.fr on mailto:panda@NOSPAMepita.fr
I'll try it out as soon as possible of of -current.
Great job !
Comments
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
By Matt Van Mater () on
Isn't a similar technology to CARP found in Cisco products? I would think the same rules apply in both scenarios.
By Dan () on
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
By Dan () on
By Dan () on
By Dan () on
Comments
By Fábio Olivé Leite () olive at unixforge.org on mailto:olive at unixforge.org
By Test () on
By lx () on
VRID dependencies/monitored circuits do in a good VRRP implementation.
Comments
By Anonymous Coward () on