Steve, I suspect that the problem is a TCP *fragment* matching a rule that is for any protocol. This happens because there is both nothing for it to match in the NAT fragment cache and because it is a fragment, it won't match a TCP map rule. The "nflags" value represents the overlap of the rule properties with that of the packet, so it being clear is quite ok.
The patch below should mitigate the problem for now, but I want to look into it more before deciding that is the final/correct fix. Thank you for the excellent problem report information, it has made diagnosing it very easy :) If you have time, please create a but report on sourceforge: https://sourceforge.net/tracker/?func=add&group_id=169098&atid=849053 Thanks, Darren Index: ip_nat.c =================================================================== RCS file: /devel/CVS/IP-Filter/ip_nat.c,v retrieving revision 2.195.2.105 diff -u -r2.195.2.105 ip_nat.c --- ip_nat.c 21 Dec 2007 23:03:24 -0000 2.195.2.105 +++ ip_nat.c 6 Feb 2008 12:26:22 -0000 @@ -2587,7 +2587,7 @@ nat->nat_ptr = np; nat->nat_p = fin->fin_p; nat->nat_mssclamp = np->in_mssclamp; - if (nat->nat_p == IPPROTO_TCP) + if (nat->nat_p == IPPROTO_TCP && tcp != NULL) nat->nat_seqnext[0] = ntohl(tcp->th_seq); if ((np->in_apr != NULL) && ((ni->nai_flags & NAT_SLAVE) == 0)) @@ -3677,7 +3677,7 @@ else ifq2 = NULL; - if (nat->nat_p == IPPROTO_TCP && ifq2 == NULL) { + if (nat->nat_p == IPPROTO_TCP && ifq2 == NULL && tcp != NULL) { u_32_t end, ack; u_char tcpflags; tcphdr_t *tcp;
