Hello,
disclaimer: I have no chance to run pfsync on production, I'm very
inexperienced with pfsync(4).
</snip>
>
> the third problem is that pf_route relies on information from rules to
> work correctly. this is a problem in a pfsync environment because you
> cannot have the same ruleset on both firewalls 100% of the time, which
> means you cannot have route-to/reply-to behave consistently on a pair of
> firwalls 100% of the time.
>
> my solution to both these problems is reduce the amount of information
> pf_route needs to work with, to make sure that the info it does need
> is in the pf state structure, and that pfsync handles it properly.
>
> if we limit the information needed for pf_route to a nexthop address,
> and which direction the address is used, this is doable. both the
> pf_state and pfsync_state structs already contain an address to store a
> nexthop in, i just had to move the route-to direction from the rule into
> the state. this is easy with pf_state, but i used a spare pad field in
> pfsync_state for this.
>
it seems to me 'route-to vs. pfsync' still needs more thought. the
next-hop IP address in route-to may be different for each PF box
linked by pfsync(4). To be honest I have no answer to address this
issue at the moment.
>
> thoughts?
>
What you've said makes sense. However I still feel pfsync(4)
does not play well with route-to.
thanks and
regards
sashan
