ip6tables with raw table(no conntrack) drop fragmented packet

[Larry Larson]

Greetings,

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

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

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
*raw
:PREROUTING ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A PREROUTING -p udp -m udp --dport 53 -j NOTRACK
-A PREROUTING -p udp -m udp --sport 53 -j NOTRACK
-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

Thanks in advance!!

Larry

[/dev/rob0]

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:

[Larry Larson]

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

_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
bind-...@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users