Bug 216867

Summary: IPFW workstation rules block DNSSEC resulting in DNS failure on freebsd.org domains
Product: Base System Reporter: MacGyver <freebsd-bugs>
Component: confAssignee: freebsd-ipfw mailing list <ipfw>
Status: New ---    
Severity: Affects Some People CC: feld, freebsd, rgrimes
Priority: ---    
Version: 11.0-RELEASE   
Hardware: amd64   
OS: Any   

Description MacGyver 2017-02-06 21:12:25 UTC
The default IPFW "workstation" rules seem to block fragmented packets caused by DNSSEC, in turn causing DNS to fail for some domains (including freebsd.org subdomains) when DNS resolution is performed locally (using BIND or Unbound).

The addition of the IPFW rule "ipfw add reass udp from any to any in" to /etc/rc.firewall, under type workstation, fixes the issue.

This issue was discussed at:
Comment 1 Mark Felder freebsd_committer 2017-03-07 13:49:25 UTC
Needs some testers, but this should fix it

Comment 2 Helge Oldach 2018-03-11 16:22:31 UTC
(In reply to Mark Felder from comment #1)
Tested and works.

However the reass should come *before* the check-state as fragments (except the first) don't include protocol and port numbers and thus cannot match check-state anyway. We need to reassemble first, then check-state will do the right thing. (It doesn't harm to implement as proposed, but we may save a few cycles if we reass first.)

Furthermore, along the same line we should not only reassemble UDP but any IP packet (including IPv6), which is also suggested by ipfw(8) manpage:

             Usually a simple rule like:

                   # reassemble incoming fragments
                   ipfw add reass all from any to any in

             is all you need at the beginning of your ruleset.
Comment 3 Rodney W. Grimes freebsd_committer 2018-03-11 16:45:51 UTC
(In reply to Helge Oldach from comment #2)

In general the reass should come before any rule that might check
a port number, as only the first packet, or a completly reassembled
packet has a port number.

So I agree it should be moved before the check state, and probably
moved even much earlier.

The other issue is that net.inet.ip.fw.one_pass must be turned on
for this to work, that change requires further considerations and