On Tue, 29 Oct 2024, at 3:11 PM, Matt Zagrabelny wrote: > Hello, > > The kernel of my DNS server is dropping packets: > > kernel: [48074703.302657] nf_conntrack: table full, dropping packet. > > I've followed this knowledge base article: > > https://kb.isc.org/docs/aa-01183 > > for configuring iptables to not track the connections of DNS packets. > > ...but it is still dropping packets due to the CT. > > I know I could bump the conntrack memory, but I'd still like to know > why my iptables rules aren't sufficient for not dropping DNS packets. > > I'm running Linux 3.2.0-4-amd64 > > Here are my iptables rules: > > # iptables -vnL -t raw > Chain PREROUTING (policy ACCEPT 24M packets, 2112M bytes) > pkts bytes target prot opt in out source destination > 16M 1153M CT udp -- * * 0.0.0.0/0 > 0.0.0.0/0 udp dpt:53 CT notrack > 3723K 701M CT udp -- * * 0.0.0.0/0 > 0.0.0.0/0 udp spt:53 CT notrack > > Chain OUTPUT (policy ACCEPT 24M packets, 5436M bytes) > pkts bytes target prot opt in out source destination > 3760K 327M CT udp -- * * 0.0.0.0/0 > 0.0.0.0/0 udp dpt:53 CT notrack > 16M 4680M CT udp -- * * 0.0.0.0/0 > 0.0.0.0/0 udp spt:53 CT notrack > > # iptables -vnL > Chain INPUT (policy DROP 45173 packets, 2842K bytes) > pkts bytes target prot opt in out source destination > 23M 2065M ACCEPT all -- * * 0.0.0.0/0 > 0.0.0.0/0 ctstate RELATED,ESTABLISHED,UNTRACKED > 11 804 ACCEPT all -- lo * 0.0.0.0/0 0.0.0.0/0 > 4 284 ACCEPT udp -- * * 0.0.0.0/0 > 0.0.0.0/0 udp dpt:53 > 709K 37M ACCEPT tcp -- * * 0.0.0.0/0 > 0.0.0.0/0 tcp dpt:53 > > Chain FORWARD (policy DROP 0 packets, 0 bytes) > pkts bytes target prot opt in out source destination > > Chain OUTPUT (policy ACCEPT 24M packets, 5439M bytes) > pkts bytes target prot opt in out source destination > > Any ideas what I'm missing? Please use iptables-save -c for dumping rulesets. You can inspect the contents of the conntrack table by using the conntrack(8) utility from conntrack-tools and, in so doing, better understand the manner in which it comes to be full. By default, TCP sessions that aren't formally ended can occupy a conntrack table entry for up to a week, per the value of the "net.netfilter.nf_conntrack_tcp_timeout_established" sysctl. Also, "net.nf_conntrack_max" can be used to increase the maximum number of entries. There is nothing wrong with tuning these controls in accordance with your workload, if needs be. Incidentally, your ruleset allows for packets classified as INVALID to traverse the INPUT chain in full, which isn't advisable. As was discussed recently, either contend with INVALID packets up front or additionally match on the NEW state for subsequent rules, where appropriate. Finally, you might consider whether you need bother using iptables at all, since this ruleset doesn't appear to be doing a great deal. Are you trying to limit the exposure of other network services that this host is running? If so, binding them to a particular address may be an option. Further, there are various scenarios in which connection tracking isn't necessarily useful, in which case one is certainly not obliged to use it. That your host isn't tasked with forwarding packets indicates that you should at least ponder upon this. -- Kerin Millar
