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
