ip6tables with raw table(no conntrack) drop fragmented packet

/dev/rob0 rob0 at gmx.co.uk
Sat Oct 1 18:21:28 UTC 2016


On Fri, Sep 30, 2016 at 11:55:18PM -0400, Larry Larson wrote:
> I've followed instructions in this BIND Knowledge base article and 
> installed ip6tables on my DNS server, using raw table with no 
> conntrack for DNS: 
> https://kb.isc.org/article/AA-01183/0/Linux-connection-tracking-and-DNS.html

This is mostly for authoritative servers which must be open to 
queries from anywhere.  Perhaps this is not a real issue, as it 
sounds like you might be setting up a recursive server?  Of course, 
it CAN be a problem for recursive-only servers too; it just depends 
how many users and concurrent queries you need to support.  If your 
userbase can flood your conntrack table, you need this.

> But for IPv6 it drops fragmented packets, for example this query 
> fails once the ip6table is on:
> dig +dnssec  isc.org any  @2001:500:60::30

Can you show us how you found out that it was affecting fragments?
Is this query falling back to TCP?  Do you have a pcap?

> Everything works great for IPv4 with similar rules, can someone 
> help shed some light on what might be wrong:
> 
> # Firewall configuration written by system-config-firewall

A minor issue, the NOTRACK target is deprecated by CT with the 
--notrack option. (That's not the problem, however.)

We can test things with a few TRACE rules.  Let's add rules as 
follows:

> *raw
> :PREROUTING ACCEPT [0:0]
> :OUTPUT ACCEPT [0:0]
-A PREROUTING -s 2001:500:60::30 -j TRACE
-A PREROUTING -d 2001:500:60::30 -j TRACE
> -A PREROUTING -p udp -m udp --dport 53 -j NOTRACK
> -A PREROUTING -p udp -m udp --sport 53 -j NOTRACK
-A OUTPUT -s 2001:500:60::30 -j TRACE
-A OUTPUT -d 2001:500:60::30 -j TRACE
> -A OUTPUT -p udp -m udp --dport 53 -j NOTRACK
> -A OUTPUT -p udp -m udp --sport 53 -j NOTRACK
> COMMIT
> *filter
> :INPUT ACCEPT [0:0]
> :FORWARD ACCEPT [0:0]
> :OUTPUT ACCEPT [0:0]
> -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED,UNTRACKED -j ACCEPT
> -A INPUT -p ipv6-icmp -j ACCEPT
> -A INPUT -i lo -j ACCEPT
> #tcp dns
> -A INPUT -m conntrack --ctstate NEW -m tcp -p tcp --dport 53 -j ACCEPT
> -A INPUT -m conntrack --ctstate NEW -m tcp -p tcp --sport 53 -j ACCEPT
> -A INPUT -j REJECT --reject-with icmp6-adm-prohibited
> -A FORWARD -j REJECT --reject-with icmp6-adm-prohibited
> COMMIT

For TRACE rules to work the LOG module must be loaded.  A quick, 
temporary way to do that:
   # ip6tables -A INPUT -i bogus -j LOG
   # ip6tables -D INPUT -i bogus -j LOG
(That adds and then removes a no-op rule using the LOG target.)

Then repeat your test,
> dig +dnssec  isc.org any  @2001:500:60::30
on this machine.

Then show us "ip6tables-save -c" along with all the "TRACE" lines 
from dmesg.  A quick way which should work for that:
   # dmesg | grep TRACE

After the test, you might want to disable those TRACE rules, in case 
you had other business with 2001:500:60::30 -- they can get very 
noisy, very quickly.

Coincidentally, I happen to be working on this very issue, with a 
different approach: shortened TTL for conntrack entries for UDP DNS.
It came up on the Netfilter mailing list recently.  I'll be sure to 
post here when that (a documentation patch) is completed.
-- 
  http://rob0.nodns4.us/
  Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:


More information about the bind-users mailing list