Date: Wed, 2 Dec 2015 12:39:47 +0800 From: Julian Elischer <julian@freebsd.org> To: elof2@sentor.se, Mark Felder <feld@FreeBSD.org> Cc: freebsd-net <freebsd-net@freebsd.org>, wishmaster <artemrts@ukr.net> Subject: Re: IPFW blocked my IPv6 NTP traffic Message-ID: <565E7613.1070303@freebsd.org> In-Reply-To: <alpine.BSF.2.00.1512011702240.54839@farmermaggot.shire.sentor.se> References: <1448920706.962818.454005905.61CF9154@webmail.messagingengine.com> <1448956697.854911427.15is5btc@frv34.fwdcdn.com> <1448982333.1269981.454734633.11BA4DB2@webmail.messagingengine.com> <alpine.BSF.2.00.1512011702240.54839@farmermaggot.shire.sentor.se>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <trusted_networks> to > <customer_nets> port 22 keep state label "VpnIN - SSH" > pass out quick on em1 inet proto tcp from <trusted_networks> to > <customer_nets> 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" >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?565E7613.1070303>