Bug 216867 - IPFW workstation rules block DNSSEC resulting in DNS failure on freebsd.org domains
Summary: IPFW workstation rules block DNSSEC resulting in DNS failure on freebsd.org d...
Status: New
Alias: None
Product: Base System
Classification: Unclassified
Component: conf (show other bugs)
Version: 11.0-RELEASE
Hardware: amd64 Any
: --- Affects Some People
Assignee: freebsd-ipfw (Nobody)
Depends on:
Reported: 2017-02-06 21:12 UTC by MacGyver
Modified: 2021-06-03 05:34 UTC (History)
2 users (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
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