Date: Wed, 26 Mar 2014 17:42:19 +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%2BSuFueLy-a0ca3U3FQp8LjdfFBsUJwVy1oBj-=vUJUNXXA@mail.gmail.com> In-Reply-To: <CAPS9%2BSst-Odzn_NQOCjMGHUfkU2BMgsZq0%2B_OJZAxVdV-4Wgmg@mail.gmail.com> 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> <CAPS9%2BSst-Odzn_NQOCjMGHUfkU2BMgsZq0%2B_OJZAxVdV-4Wgmg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
... snip ... >> 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 > And now it happened on another machine, but different type of traffic. Traffic triggering the divert rule work fine, some traffic not triggering the divert rule does not. After everything works as expected. Before reboot I flushed the firewall so that only default rule was in play ( allow all from any to any ), and then *no* traffic for that destination went out of the box. There are something like ~1000 routes in the routing table. Routes are added and removed according to some triggers, so during uptime of the machine there is a bit of messing with the routing table. At this stage I'm at a loss on how to continue investigating this, so I'll just implement the forwarding via fwd rules in ipfw and altogether ignore the routing table. Best regards Andreas
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAPS9%2BSuFueLy-a0ca3U3FQp8LjdfFBsUJwVy1oBj-=vUJUNXXA>