Date: Mon, 02 Jul 2018 18:37:39 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 229477] [PATCH] fail-policy changes cause delays on synproxy packets Message-ID: <bug-229477-227@https.bugs.freebsd.org/bugzilla/>
next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=229477 Bug ID: 229477 Summary: [PATCH] fail-policy changes cause delays on synproxy packets Product: Base System Version: 11.2-STABLE Hardware: Any OS: Any Status: New Severity: Affects Some People Priority: --- Component: kern Assignee: bugs@FreeBSD.org Reporter: mail@fbsd.e4m.org Created attachment 194842 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=194842&action=edit Patch to bring back synproxy functionality I was wondering why synproxy rules performed so badly after the recent pf changes implementing the fail-policy. Please have a look at my patch: 1. Shouldn't the return(action) statement be performed ALWAYS if action != PF_PASS? 2. If I understand pf_return() correctly, a RST is sent in case of TCP connections. But it's probably not OK to send a RST if "action" came back with PF_SYNPROXY_DROP. Is it OK to catch this with my additional "action == PF_DROP" condition or do we need something more sophisticated? While I am sure about 1., I am unsure about 2. (I just had a quick look at pf_return() so maybe I missed something). -- You are receiving this mail because: You are the assignee for the bug.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-229477-227>