Okay I have taken the live box offline, and have built a lab with an identical configuration, and I actually am able to reproduce the problem at will now.
I setup my lab environment to exactly mirror the live site, and I went at it with the full tcp stream of traffic trying to cause the crash. And after a good long while (and a lot of packets (was pushing full 95-97Mbit for the entire period)), there was no issues. I than said well let's pick up a bunch of DoS tools off of the web and see what I can send at it (we get a lot of DoS traffic). And sure enough, I found a DoS tool that will crash it (with the error I was getting) like clockwork. I can cause it to crash in as little as 10 packets (it's an ICMP exploit btw interestingly enough (and rebuilding the kernel with no INET6 didn't help btw)). I also started taking pieces out of the kernel in an attempt to narrow it down. What I found was it only happens when I use the BIMAP piece of the puzzle (along with the proxy arp of course). I basically stripped my system down to the following. No ipf rules (so allow everything) ipnat.rules ----------- bimap fxp0 10.10.2.231/32 -> 1.2.3.231/32 map fxp0 10.10.2.0/24 -> 1.2.3.70/32 portmap tcp/udp 1025:65000 map fxp0 10.10.2.0/24 -> 1.2.3.70/32 rc.local -------- #!/bin/sh /usr/sbin/arp -S 1.2.3.231 00:50:08:00:6b:b9 pub /usr/sbin/arp -S 1.2.3.70 00:50:08:00:6b:b9 pub Everything else remained the same. And if you grab a copy of what is called 7plagues.pl (http://packetstormsecurity.nl/DoS/7plagues.pl), and look at the icmp test (the exact test is called riversOfBlood) this is the one that will kill it (you can isolate it to just that test by editing the file, and commenting out line 92) and calling it as ./7plagues.pl 1.2.3.231 icmp And within a few seconds of doing that it will reboot. You can specify a third parameter to limit the number of packets. I've been able to cause it in as few as 10 and as many as 100,000. If you send the packets at the machines REAL ip (1.2.3.1) it works just fine, it's just the BIMAP'd address that causes the failure. Upon reboot, looking at the kernel core dump, it yields EXACTLY the failure I have been seeing (the va = kbp->next bug where kbp->next points to 0x1). Greg * Steven Nikkel ([EMAIL PROTECTED]) [030528 07:20]: > That seems similar to a problem I'm seeing. I'm getting > "ICMP destination unreachable, host unreachable" packets > in the middle of connections. A source quence would actually > make sense in these case. > > I'm running IPfilter 3.4.29 on Freebsd 4.7 with nat and ipv6. > > On Wed, 28 May 2003, Guido van Rooij wrote: > > > Date: Wed, 28 May 2003 14:44:20 +0200 > > From: Guido van Rooij <[EMAIL PROTECTED]> > > To: Greg Rumple <[EMAIL PROTECTED]> > > Cc: [EMAIL PROTECTED] > > Subject: Re: FreeBSD 4.8 IPFilter/IPNat kernel panic > > > > On Wed, May 28, 2003 at 05:41:59AM -0700, Greg Rumple wrote: > > > > > > > > > > So far 2 crashs later, the packet in both cases in the ip_natin code > > > > > (print *ip) is a TCP packet. > > > > > > > > DO you have a kernel with Ipv6? > > > > > > Yeah I believe the default kernel in 4.8 (I'm using the GENERIC kernel > > > plus 4 lines added to it) most certanly does have IPv6. I'm not using > > > it, but you said that doesn't apply. And yes doing an ipfstat -hio6 > > > shows I have empty rule sets for ipv6 traffic. > > > > Hmm..I still wonder if the problem is the same, as with my friends setup > > it is always an ICMP source quench in combination with NAT. > > Haven't tracked it down though. > > > > -Guido > > > > [EMAIL PROTECTED] > ------------------------- > ERROR: Keyboard not attached. Press F1 to continue. > -- Greg Rumple [EMAIL PROTECTED]
