On Mon, Jan 26, 2004 at 04:22:36PM -0800, Scott L. Burson wrote: > So, what to do about it? Is this already being fixed? Should I enter a bug > report somewhere?
I'll try to fix it, probably pf_send_tcp() should call pf_route() when appropriate. If done right, it should also allow 'reply-to' on 'block return-rst' rules, to route the pf generated RSTs. And once that works, return-icmp should probably support that, too. Right now, the routing options (route-to, reply-to, etc.) just don't apply to pf generated packets (which includes synproxy). It's not a bug in the sense that it suprises developers, more like a missing feature. If you file an urgent bug report, the immediate reaction will be an addition to the man page, I guess you rather want code :) Routing options not being honoured in these cases is a separate problem from not evaluating rules on subsequent interfaces (and therefore potentially not applying nat translation where it might be expected). I'll postpone that to when someone actually needs it, then. I think if you bind states to interfaces (with the new 'set state-policy if-bound') you can also break synproxy, but in a different way, so evaluating ruleset on subsequent interfaces might be needed for that, too (like when you filter on two interfaces, synproxy sneaks the fake server handshake through the second interface without creating state, and then real post-handshake server traffic gets blocked because there's no state). When I have a patch, it will be against -current, are you willing to upgrade a box to test it? Daniel
