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"
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-unsubscr...@freebsd.org"
