[Bug 229092] [pf] [pfsync] States created by route-to rules pfsynced without interface

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=229092

--- Comment #2 from Kajetan Staszkiewicz <vegeta at tuxpowered.net> ---
While looking on possibility of recreating src_nodes I found that the way src
nodes are created is rather sketchy. For example when a new state is created
with new src_node, first a node is searched for, if none is found then it is
created and inserted, each of those operation with its own locking and
unlocking src_node hash. Operations within pf_map_addr operate on unlocked
src_node which probably explain crashes I had when flushing nodes on heavily
loaded system. Then there is the issue that each locking and unlocking
operation requires computing the hash again, why not compute it once and store
it within the node, this way unlocking could be a bit faster. Creation of node
could return it locked as now it needs to be re-locked for any further
operations. Then there is the issue that pf_state->rt_kif is copied from
pf_rule->rpool.cur which might not be the same as during pf_map_addr() (there
is no locking inside that function so it might be inconsistent anyway). And
last but not the least is that it seems to me that pf_src_node->*kif is not
used at all. And src_node itself never stores information about interface
choosen for route-to targets, it is only copied to state instead.

I will prepare a patch addressing those issues first and then work on
recreating redirection interface as originally this issue was about.

The proof of concept patch seems generally working, I configured my firewall
service to start before pfsync and I could reboot my load balancers as I
pleased and traffic was correctly forwarded.

-- 
You are receiving this mail because:
You are the assignee for the bug.