IPFW blocked my IPv6 NTP traffic

[Julian Elischer]

On 2/12/2015 12:27 AM, 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'?
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 at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "freebsd-net-unsubscribe at freebsd.org"
>