Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 14 Mar 2014 16:31:52 +0100
From:      Andreas Nilsson <andrnils@gmail.com>
To:        Ian Smith <smithi@nimnet.asn.au>, FreeBSD Net <freebsd-net@freebsd.org>
Subject:   Re: ipfw / routing issue on 9.2-RELEASE
Message-ID:  <CAPS9%2BSst-Odzn_NQOCjMGHUfkU2BMgsZq0%2B_OJZAxVdV-4Wgmg@mail.gmail.com>
In-Reply-To: <20140307024724.T75313@sola.nimnet.asn.au>
References:  <CAPS9%2BSsbPsQLqu9mwz7nhcn%2BjMkkj57JUeHOO3U5xm9eXLYb8g@mail.gmail.com> <531771C8.1040207@yandex.ru> <CAPS9%2BStX7Dbrh5dYJN2K_4pimc91L86YWmfWeaZ%2BgLaEDhWe5A@mail.gmail.com> <20140306145231.Q75313@sola.nimnet.asn.au> <CAPS9%2BSt7WvVYSbyjG-P=rKApakUdXeNeKq9pkcmLA6-7ZxWDSA@mail.gmail.com> <20140307024724.T75313@sola.nimnet.asn.au>

next in thread | previous in thread | raw e-mail | index | archive | help
... 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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAPS9%2BSst-Odzn_NQOCjMGHUfkU2BMgsZq0%2B_OJZAxVdV-4Wgmg>