The TCP header-specific section suffered a little bit of bitrot recently:

When we recieve a fragmented TCP packet (other than the first) we can't
extract header information (we don't have state to reference). In a rather
unelegant fashion we just move on and assume a non-match.

Recent additions to the TCP header-specific section of the code neglected
to add the logic to the fragment code so in those cases the match was
assumed to be positive and those parts of the rule (which should have
resulted in a non-match/continue) were instead skipped (which means
the processing of the rule continued even though it had already not
matched).

Fault can be spread out over Rich Steenbergen (tcpoptions) and myself
(tcp{seq,ack,win}).

rwatson sent me a patch that got me thinking about this whole situation
(but what I'm committing / this description is mine so don't blame him).

1 files changed, 1 insertions, 1 deletions

diff --git a/sys/netinet/ip_fw.c b/sys/netinet/ip_fw.c
index a17e0ad..ebb1370 100644
--- a/sys/netinet/ip_fw.c
+++ b/sys/netinet/ip_fw.c
@@ -1259,7 +1259,7 @@ again:
 				 * we consider the rule a non-match.
 				 */
 				if (f->fw_nports != 0 ||
-				    f->fw_tcpf != f->fw_tcpnf)
+				    f->fw_ipflg & IP_FW_IF_TCPMSK)
 					continue;
 
 				break;