Re: ipfilter causing kernel panic in FreeBSD 6.1

Darren Reed wrote:
> Steve Clark wrote:
>
>>...
>>Hi Darren,
>>
>>Since I knew it was night time "down under" I went ahead and just
>>changed to code
>>to print a message and return -1 in nat_finalise() then the tcp
>>pointer was null.
>>The system has stayed up now almost 24 hours - where yesterday it had
>>20 panics.
>>
>>Is there some reason we wouldn't want to just dump/ignore this packet,
>>since it seems to
>>me that the initial syn and at least the first packet of the
>>fragmented series had gotten lost
>>and eventually will be retried.
>
>
> Well, the original packet that caused this problem was not
> part of a SYN - it was a midstream TCP packet. I suspect
> something else is going on there. It may be part of a retransmitted
> packet sent after the original NAT session is torn down.
> I don't know. But obviously your policy allows the packet
> to be sent (and received) so the NAT code should make
> this possible.
>
> It might be more appropriate to not allow fragments that are
> not the first fragment (offset = 0) to form NAT sessions for
> the TCP/UDP protocols. That I could understand.
>
Yes that is what I was getting at. It is my understanding that in
freebsd ip_nat happens
before ip_filter - so we really can't filter these before they hit
ip_nat. Since they are externally
generated we would have to put another fw in front of this firewall to
keep them out.

Steve

> Darren
>
>