ip6tables with raw table(no conntrack) drop fragmented packet

Larry Larson larsonlarry66 at gmail.com
Sun Oct 2 20:04:36 UTC 2016


This is for recursive, and our recursive got 10X more queries than our
authoritative ones, and we had to disable conntrack on our DNS servers last
summer by using raw table and everything works for IPv4 including
fragmentation, we just noticed fragment fails for IPv6 when using raw
table, query not trigger fragment works fine, like this one:
dig @2001:500:60::30 isc.org

I've added the trace to the ip6table, and here is the pcap:
15:51:48.746691 IP6 (hlim 64, next-header UDP (17) payload length: 44)
2001:0468:2:183::20.45955 > 2001:500:60::30.53: [udp sum ok] 59884+ [1au]
ANY? isc.org. ar: . OPT UDPsize=4096 OK (36)
15:51:48.846080 IP6 (hlim 52, next-header Fragment (44) payload length:
1240) 2001:500:60::30 > 2001:0468:2:183::20: frag (0xefa32c05:0|1232) 53 >
45955: 59884*- q: ANY? isc.org. 27/0/16 isc.org. RRSIG, isc.org. SPF,
isc.org. RRSIG, isc.org. RRSIG, isc.org. DNSKEY, isc.org. DNSKEY, isc.org.
RRSIG[|domain]
15:51:48.846101 IP6 (hlim 52, next-header Fragment (44) payload length:
1240) 2001:500:60::30 > 2001:0468:2:183::20: frag (0xefa32c05:1232|1232)
15:51:48.846122 IP6 (hlim 52, next-header Fragment (44) payload length:
1240) 2001:500:60::30 > 2001:0468:2:183::20: frag (0xefa32c05:2464|1232)
15:51:48.846126 IP6 (hlim 52, next-header Fragment (44) payload length:
318) 2001:500:60::30 > 2001:0468:2:183::20: frag (0xefa32c05:3696|310)

Here is the dmesg:
TRACE: raw:OUTPUT:rule:3 IN= OUT=eth0
SRC=2001:0468:0002:0183:0000:0000:0000:0020
DST=2001:0500:0060:0000:0000:0000:0000:0030 LEN=84 TC=0 HOPLIMIT=64
FLOWLBL=0 PROTO=UDP SPT=38537 DPT=53 LEN=44 UID=0 GID=0
TRACE: raw:OUTPUT:policy:5 IN= OUT=eth0
SRC=2001:0468:0002:0183:0000:0000:0000:0020
DST=2001:0500:0060:0000:0000:0000:0000:0030 LEN=84 TC=0 HOPLIMIT=64
FLOWLBL=0 PROTO=UDP SPT=38537 DPT=53 LEN=44 UID=0 GID=0
TRACE: filter:OUTPUT:policy:1 IN= OUT=eth0
SRC=2001:0468:0002:0183:0000:0000:0000:0020
DST=2001:0500:0060:0000:0000:0000:0000:0030 LEN=84 TC=0 HOPLIMIT=64
FLOWLBL=0 PROTO=UDP SPT=38537 DPT=53 LEN=44 UID=0 GID=0
TRACE: raw:PREROUTING:policy:5 IN=eth0 OUT=
MAC=00:50:56:a9:44:68:00:23:9c:f5:67:f0:86:dd
SRC=2001:0500:0060:0000:0000:0000:0000:0030
DST=2001:0468:0002:0183:0000:0000:0000:0020
LEN=1280 TC=0 HOPLIMIT=52 FLOWLBL=0 OPT ( FRAG:0 INCOMPLETE ID:90c4bbe8 )
PROTO=UDP SPT=53 DPT=38537 LEN=4006
TRACE: filter:INPUT:rule:1 IN=eth0 OUT=
MAC=00:50:56:a9:44:68:00:23:9c:f5:67:f0:86:dd
SRC=2001:0500:0060:0000:0000:0000:0000:0030
DST=2001:0468:0002:0183:0000:0000:0000:0020
LEN=1280 TC=0 HOPLIMIT=52 FLOWLBL=0 OPT ( FRAG:0 INCOMPLETE ID:90c4bbe8 )
PROTO=UDP SPT=53 DPT=38537 LEN=4006
TRACE: raw:PREROUTING:policy:5 IN=eth0 OUT=
MAC=00:50:56:a9:44:68:00:23:9c:f5:67:f0:86:dd
SRC=2001:0500:0060:0000:0000:0000:0000:0030
DST=2001:0468:0002:0183:0000:0000:0000:0020
LEN=1280 TC=0 HOPLIMIT=52 FLOWLBL=0 OPT ( FRAG:1232 INCOMPLETE ID:90c4bbe8
) PROTO=UDP
TRACE: raw:PREROUTING:policy:5 IN=eth0 OUT=
MAC=00:50:56:a9:44:68:00:23:9c:f5:67:f0:86:dd
SRC=2001:0500:0060:0000:0000:0000:0000:0030
DST=2001:0468:0002:0183:0000:0000:0000:0020
LEN=1280 TC=0 HOPLIMIT=52 FLOWLBL=0 OPT ( FRAG:2464 INCOMPLETE ID:90c4bbe8
) PROTO=UDP
TRACE: raw:PREROUTING:policy:5 IN=eth0 OUT=
MAC=00:50:56:a9:44:68:00:23:9c:f5:67:f0:86:dd
SRC=2001:0500:0060:0000:0000:0000:0000:0030
DST=2001:0468:0002:0183:0000:0000:0000:0020
LEN=358 TC=0 HOPLIMIT=52 FLOWLBL=0 OPT ( FRAG:3696 ID:90c4bbe8 ) PROTO=UDP
TRACE: raw:OUTPUT:rule:3 IN= OUT=eth0
SRC=2001:0468:0002:0183:0000:0000:0000:0020
DST=2001:0500:0060:0000:0000:0000:0000:0030 LEN=84 TC=0 HOPLIMIT=64
FLOWLBL=0 PROTO=UDP SPT=38537 DPT=53 LEN=44 UID=0 GID=0


Thanks!

Larry

On Sat, Oct 1, 2016 at 2:21 PM, /dev/rob0 <rob0 at gmx.co.uk> wrote:

> 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:
> _______________________________________________
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to
> unsubscribe from this list
>
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20161002/0319970d/attachment-0001.html>


More information about the bind-users mailing list