IPFW blocked my IPv6 NTP traffic

[Mark Felder]

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
 
>  In general on public interface you should:
>  $cmd 12345 allow log all from any to me 123 $ks
> 
>  And for outgoing traffic just:
>  $cmd 1234 allow log all from me to any $ks
> 
>  This works for me.
> 

Sure, I understand the risks and the workaround here but it just seems
odd that I have to do this for ipv6 when ipv4 has worked fine. With UDP
not really having "state" I understand why that traffic was blocked
because the NTP server was trying to send data to my port 58285. I did a
tcpdump and restarted ntpd to see what I could find other instances of
this in the ipv4 traffic:

root at gw:/usr/home/feld # tcpdump -i re0 -nttt dst port 123
tcpdump: verbose output suppressed, use -v or -vv for full protocol
decode
listening on re0, link-type EN10MB (Ethernet), capture size 262144 bytes
00:00:00.000000 IP 68.117.126.78.123 > 129.6.15.29.123: NTPv4, Client,
length 48
00:00:00.105172 IP 129.6.15.29.123 > 68.117.126.78.123: NTPv4, Server,
length 48
00:00:01.894636 IP 68.117.126.78.123 > 209.114.111.1.123: NTPv4, Client,
length 48
00:00:00.000068 IP 68.117.126.78.123 > 129.6.15.29.123: NTPv4, Client,
length 48
00:00:00.065549 IP 209.114.111.1.123 > 68.117.126.78.123: NTPv4, Server,
length 48
00:00:00.045821 IP 129.6.15.29.123 > 68.117.126.78.123: NTPv4, Server,
length 48
00:00:01.888500 IP 68.117.126.78.123 > 209.114.111.1.123: NTPv4, Client,
length 48
00:00:00.000066 IP 68.117.126.78.123 > 129.6.15.29.123: NTPv4, Client,
length 48
00:00:00.064383 IP 209.114.111.1.123 > 68.117.126.78.123: NTPv4, Server,
length 48
00:00:00.042029 IP 129.6.15.29.123 > 68.117.126.78.123: NTPv4, Server,
length 48
00:00:01.893509 IP 68.117.126.78.123 > 209.114.111.1.123: NTPv4, Client,
length 48
00:00:00.000061 IP 68.117.126.78.123 > 129.6.15.29.123: NTPv4, Client,
length 48
00:00:00.064418 IP 209.114.111.1.123 > 68.117.126.78.123: NTPv4, Server,
length 48
00:00:00.044275 IP 129.6.15.29.123 > 68.117.126.78.123: NTPv4, Server,
length 48
00:00:01.891510 IP 68.117.126.78.123 > 209.114.111.1.123: NTPv4, Client,
length 48
00:00:00.000068 IP 68.117.126.78.123 > 129.6.15.29.123: NTPv4, Client,
length 48
00:00:00.063342 IP 209.114.111.1.123 > 68.117.126.78.123: NTPv4, Server,
length 48
00:00:00.044807 IP 129.6.15.29.123 > 68.117.126.78.123: NTPv4, Server,
length 48
00:00:01.891549 IP 68.117.126.78.123 > 209.114.111.1.123: NTPv4, Client,
length 48
00:00:00.000067 IP 68.117.126.78.123 > 129.6.15.29.123: NTPv4, Client,
length 48
00:00:00.065415 IP 209.114.111.1.123 > 68.117.126.78.123: NTPv4, Server,
length 48
00:00:00.038239 IP 68.117.126.78.16205 > 69.164.201.165.123: NTPv4,
Client, length 48
00:00:01.896362 IP 68.117.126.78.123 > 209.114.111.1.123: NTPv4, Client,
length 48
00:00:00.064590 IP 209.114.111.1.123 > 68.117.126.78.123: NTPv4, Server,
length 48
00:00:06.057206 IP 68.117.126.78.16205 > 4.53.160.75.123: NTPv4, Client,
length 48
00:00:08.003668 IP 68.117.126.78.16205 > 72.20.40.62.123: NTPv4, Client,
length 48
00:00:08.051264 IP 68.117.126.78.16205 > 104.131.53.252.123: NTPv4,
Client, length 48


Notice how almost all of them are port 123 on both sides, but a few of
them are not. Why? The RFC says that NTP is supposed to be using port
123 as both the source and destination port, but I clearly have
something happening on port 16205. Is something screwy with ntpd in
CURRENT?


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