From owner-freebsd-net@freebsd.org Tue Dec 1 18:08:27 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 9EDD6A3EDED for ; Tue, 1 Dec 2015 18:08:27 +0000 (UTC) (envelope-from gpalmer@freebsd.org) Received: from mail.in-addr.com (mail.in-addr.com [IPv6:2a01:4f8:191:61e8::2525:2525]) (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 647AD1F84; Tue, 1 Dec 2015 18:08:27 +0000 (UTC) (envelope-from gpalmer@freebsd.org) Received: from gjp by mail.in-addr.com with local (Exim 4.86 (FreeBSD)) (envelope-from ) id 1a3pLl-0002Rg-Eg; Tue, 01 Dec 2015 18:08:25 +0000 Date: Tue, 1 Dec 2015 18:08:25 +0000 From: Gary Palmer To: Mark Felder Cc: freebsd-net@freebsd.org Subject: Re: IPFW blocked my IPv6 NTP traffic Message-ID: <20151201180825.GA79605@in-addr.com> References: <1448920706.962818.454005905.61CF9154@webmail.messagingengine.com> <1448956697.854911427.15is5btc@frv34.fwdcdn.com> <1448982333.1269981.454734633.11BA4DB2@webmail.messagingengine.com> <1448982799.434403138.1awkb6gu@frv34.fwdcdn.com> <1448992847.1321736.454930393.6EE09773@webmail.messagingengine.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1448992847.1321736.454930393.6EE09773@webmail.messagingengine.com> X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: gpalmer@freebsd.org X-SA-Exim-Scanned: No (on mail.in-addr.com); SAEximRunCond expanded to false 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: Tue, 01 Dec 2015 18:08:27 -0000 On Tue, Dec 01, 2015 at 12:00:47PM -0600, Mark Felder wrote: > > > On Tue, Dec 1, 2015, at 09:16, wishmaster wrote: > > > > --- Original message --- > > From: "Mark Felder" > > Date: 1 December 2015, 17:05:35 > > > > > > > > > > > > > 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 > > > > > > > > > > Strange... I looked at ntpq output and sure enough I was trying to > > > > > communicate with that server. But why was it getting blocked? I don't > > > > > have a rule to allow IPv4 input from source port 123. I expected IPFW to > > > > > handle this for me. I know UDP is stateless, but firewalls are usually > > > > > able to "keep state" for UDP. I looked at my v4 rules which and I have > > > > > keep-state on there: > > > > > > > > > > # Allow all outgoing, skip to NAT > > > > > ###################################### > > > > > $cmd 01300 skipto 5000 tcp from any to any out via $pif $ks > > > > > $cmd 01310 skipto 5000 udp from any to any out via $pif $ks > > > > > $cmd 01320 skipto 5000 icmp from any to any out via $pif > > > > > ###################################### > > > > > > > > > > I noticed my outbound IPv6 didn't have $ks for udp, so I added it. > > > > > However, that had no effect. The solution was to add an incoming rule: > > > > > > > > > > $cmd 03755 allow udp from any to any src-port 123 in via $pif6 $ks > > > > > > > > > > This seems wrong. Thoughts? > > > > > > > > > > > > > What is your 5000 rule? > > > > > > > > > > $cmd 05000 nat 1 ip4 from any to any out via $pif > > > > Hey. As I understand, there is a problem in connection clients from Inet > > with your NTP server. If yes, why do you use NAT rule? > > > > > > That's the NAT rule for my home network for outbound IPv4. It's working > as expected. > > Outbound NTP traffic on high ports (not 123) works fine with IPv4. The > reply from the NTP server is allowed through, presumably from the > keep-state rule on outbound UDP traffic. > > Outbound NTP traffic on high ports with IPv6 is allowed outbound but the > replies denied inbound. This has been my source of confusion and concern > considering it should have been allowed by keep-state. Have you looked at the ipfw state tables to see if a state is recorded? ipfw -d list I think Gary