ipfw / routing issue on 9.2-RELEASE

[Andreas Nilsson]

... 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