... snip ...
> Ah. Well it was good to see the rules listed anyway, always helps. > > > Was the count rules something like: > > > > 00001 901 46132 skipto 63000 ip from table(1) to any in recv > > table(8) > > > > ... same as before ... > > > > 63500 895 45844 count log logamount 100 ip from table(1) to > any in > > recv table(8) > > > > 64000 0 0 fwd tablearg ip from table(12) to any > > > > 64500 895 45844 count log logamount 100 ip from table(1) to > any in > > recv table(8) > > 65535 3849164 1234591611 allow ip from any to any > > > > So everything looks nice enough, but still no go. Interestingly enough, > > since this is a production machine I can't fool around to much ( that's > why > > it took a while to get the above results ) I tried to reproduce this on > > another machine. Lo and behold, I couldn't. There it worked with the > > skipto-version. I'll investigate this and see if I can find any > differences. > > I'm wondering what's happening on the outbound path, most of your rules > handle inbound (to kernel) and it seems that rule 65535 deals with most > outbound, except those specifically acting on both paths. > So do I :) > > Maybe try adding to the above: > ipfw add 63510 count log ip from table(1) to any out recv table(8) > and > ipfw add 64510 count log ip from table(1) to any out recv table(8) > > which should catch them on the outbound path before the default rule; > outbound packets have both receive and transmit interfaces available. > > They never get that far :( Those rules log nothing. So I see the packet coming in, triggering the skipto, triggering the count log ... in recv but not the count log ... out. > I guess you're sure that these packets are actually going out to some > external address, not a localhost or alias address (which of course are > received and not sent out anywhere)? > Yes, when the go through they go to external address, which is in the routing table. > > I guess the above new log lines should show the interface (if any) > these packets are leaving on, after routing (maybe a routing issue?) > > Good luck hunting. If in doubt, throw ever more logging at it! :) And > please let the list know if you solve it - or not! > > cheers, Ian > To make it even more interesting, it tested this on another machine, where I'm unable to reproduce this "problem". I'm thinking that a reboot might help, but this is kind of fascinating so I would like to actually find the cause. I will investigate further. Best regards Andreas _______________________________________________ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"