From owner-freebsd-net@freebsd.org Wed Dec 2 04:40:06 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B3E7FA3FDAF for ; Wed, 2 Dec 2015 04:40:06 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 81D5D1542; Wed, 2 Dec 2015 04:40:06 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from Julian-MBP3.local (50-196-156-133-static.hfc.comcastbusiness.net [50.196.156.133]) (authenticated bits=0) by vps1.elischer.org (8.15.2/8.15.2) with ESMTPSA id tB24drc7009490 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 1 Dec 2015 20:39:57 -0800 (PST) (envelope-from julian@freebsd.org) Subject: Re: IPFW blocked my IPv6 NTP traffic To: elof2@sentor.se, Mark Felder References: <1448920706.962818.454005905.61CF9154@webmail.messagingengine.com> <1448956697.854911427.15is5btc@frv34.fwdcdn.com> <1448982333.1269981.454734633.11BA4DB2@webmail.messagingengine.com> Cc: freebsd-net , wishmaster From: Julian Elischer Message-ID: <565E7613.1070303@freebsd.org> Date: Wed, 2 Dec 2015 12:39:47 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2015 04:40:06 -0000 On 2/12/2015 12:27 AM, elof2@sentor.se wrote: > On Tue, 1 Dec 2015, Mark Felder wrote: > >> >> >> On Tue, Dec 1, 2015, at 02:02, wishmaster wrote: >>> >>> Hi, Mark. >>> >>> >>>> I'm hoping someone can explain what happened here and this isn't >>>> a bug, >>>> but if it is a bug I'll gladly open a PR. >>>> >>>> I noticed in my ipfw logs that I was getting a log of "DENY" >>>> entries for >>>> an NTP server >>>> >>>> Nov 30 13:35:16 gw kernel: ipfw: 4540 Deny UDP >>>> [2604:a880:800:10::bc:c004]:123 [2001:470:1f11:1e8::2]:58285 in >>>> via gif0 > > Three long-shots: > > 1) > I see that you use a gif interface. That makes me wonder: > Do the 'keep-state' function in 'ipfw' work as bad as it does in 'pf'? Not to solve the problem here, but to give some general education, the keep-state in ipfw keeps a pointer to the action section of the rule that generates it, and if another packet from the same session is detected, the same action section is executed again. so, for example if the action section is "skipto 2" it will skip to rule 2, regardless of where it is. (it's theoretically possible to crash/hang your system that way by having a rule skip to a rule before itself, which is not normally allowed). No notice is taken of where ipfw was called from or what interface introduced the packet.. Only source and destination addresses (and ports) and the protocol are examined. (no ports if icmp). > > In pf, 'keep state" doesn't keep state between software network > interfaces and real network interfaces. So if I allow something in > via tun0 (a software OpenVPN NIC), with keep state, the response is > *not* automatically (via the state table) allowed back in on the > ethernet NIC it was sent out. So for all my VPN-rules, I have to > make two of them like this: > > Pf example: > pass in quick on tun0 inet proto tcp from to > port 22 keep state label "VpnIN - SSH" > pass out quick on em1 inet proto tcp from to > port 22 keep state label "DmzOUT - SSH" > > > > 2) > Is this hapening over and over, or was it just a one time thing? > If the latter, could it be that you flushed your firewall state > table just after a cron job ran 'ntpdate 2604:a880:800:10::bc:c004', > so the query got out but immediately after the state table was > emptied and hence the response got blocked? > > > > 3) > If 2001:470:1f11:1e8::2 is not the ipfw node itself, but some node > behind it, could the ntp query to 2604:a880:800:10::bc:c004 have > taken a different path? I.e. the ipfw node doesn't see the query, > but the response packet is routed to it, so it gets blocked. > > /Elof > _______________________________________________ > freebsd-net@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >