On Mon, May 08, 2006 at 06:21:47PM +0200, Daniel Hartmeier wrote:
> > Can this be achieved using pfsync? If so, what do I need to do to get
> > this working? If not, can pfsync be extended to allow for this or
> > should we look into something different altogether?
>
> This currently won't work. pfsync does only synchronize state table
> entries, not rules. Since the firewalls can have different rules, no
> attempt is made to associate a state entry with a particular rule of the
> recipient's ruleset. Instead, such state entries are associated with
> the default pass rule.
>
> Because of that, many rule options (like source tracking in your case)
> are lost on the recipient node. Both firewalls would insert the other's
> state entries, but those would not be counted towards the limit.
>
> Ryan had plans to work on this, but I don't know about any progress.
> It's not something trivial, and may only work with completely equal
> ruleset (or at least well-defined mappings between rules on both nodes).
Actually, preliminary code to match states to the correct rule is in
3.9:
/*
* If the ruleset checksums match, it's safe to associate the state
* with the rule of that number.
*/
if (sp->rule != htonl(-1) && sp->anchor == htonl(-1) && chksum_flag)
r = pf_main_ruleset.rules[
PF_RULESET_FILTER].active.ptr_array[ntohl(sp->rule)];
else
r = &pf_default_rule;
If the rulesets are "identical", states created by rules in the
main ruleset are associated with the correct rule on the recieving
firewall. This means that things like state limits, tcp timeouts, and
queues will work correctly.
You can check the ruleset checksum with pfctl -vsi, to make sure that
the rulesets will support this function.
Note that it doesn't work for anchor rulesets, and we're still not
matching states to the correct NAT rule. Hopefully I'll get a chance to
fix some of this stuff before the next release, possibly at the
hackathon.
-Ryan
