IPFW blocked my IPv6 NTP traffic

[Mark Felder]

On Tue, Dec 1, 2015, at 10:27, elof2 at 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'?
> 
> 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"
> 
> 

That's an interesting idea. I wonder if that's happening here.

> 
> 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?
> 

Nope, I don't run ntp via cron

> 
> 
> 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.
> 

2001:470:1f11:1e8::2 is my firewall where ntpd runs. There are no
alternate paths, but this is also a clever idea if I was multihomed and
was running bgp with some routes preferred out different interfaces.


-- 
  Mark Felder
  ports-secteam member
  feld at FreeBSD.org