Date: Tue, 8 Apr 2014 00:23:05 +0200 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%2BSu=9J4Z3A-FVEAzzQHkyiVU3WuX7-ARNwovCFofyWH=Rg@mail.gmail.com> In-Reply-To: <CAPS9%2BSuFueLy-a0ca3U3FQp8LjdfFBsUJwVy1oBj-=vUJUNXXA@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> <CAPS9%2BSuFueLy-a0ca3U3FQp8LjdfFBsUJwVy1oBj-=vUJUNXXA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Mar 26, 2014 at 5:42 PM, Andreas Nilsson <andrnils@gmail.com> wrote: > ... 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 > Ok, found the culprit: -# $FreeBSD: releng/9.1/etc/rc.d/netif 212579 2010-09-13 19:55:40Z hrs $ +# $FreeBSD: releng/9.2/etc/rc.d/netif 253238 2013-07-12 01:34:24Z hrs $ + if [ -f /etc/rc.d/routing -a -n "$cmdifn" ] ; then + for _if in $cmdifn; do + /etc/rc.d/routing start any $_if + done + fi etc/rc.d/routing enforces gateway_enable setting in rc.conf which does not play well with setting net.inet.ip.forwarding=1 in sysctl.conf directly. Very annoying. I can find nothing i UPDATING on the subject. Even more annoying. Best regards Andreas
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAPS9%2BSu=9J4Z3A-FVEAzzQHkyiVU3WuX7-ARNwovCFofyWH=Rg>