[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

netfilter related regression in linux-image 3.16.43-2?

Dear all,

after upgrading a mail server to the recent 8.8 Jessie point release my
monitoring showed a significantly decreased amount of inbound SMTP
traffic. Specifically, after rebooting for kernel upgrade from
linux-image-3.16.0-4-686-pae 3.16.39-1+deb8u2 to 3.16.43-2

I found that a large number of outgoing SYN-ACK packets were being
dropped by netfilter:

[BLOCKED:OUTPUT] IN= OUT=ppp0 SRC=x.x.x.x DST=y.y.y.y LEN=60 TOS=0x00
PREC=0x00 TTL=64 ID=0 DF PROTO=TCP SPT=25 DPT=45809 WINDOW=28800

[BLOCKED:OUTPUT] IN= OUT=ppp0 SRC=x.x.x.x DST=z.z.z.z LEN=52 TOS=0x00
PREC=0x00 TTL=64 ID=0 DF PROTO=TCP SPT=25 DPT=61847 WINDOW=29040

Here, x.x.x.x is my server's IPv4 address, y.y.y.y, z.z.z.z are
addresses of two hosts attempting to deliver mail.

Relevant part of iptables config (the idea being that outbound TCP
connections are not allowed from this host except for some well known
destination ports):

$IPTB -A OUTPUT -p tcp -o $IF_UPL -m state --state ESTABLISHED,RELATED
$IPTB -A OUTPUT -p tcp -o $IF_UPL -m multiport --dports smtp,... -m

$IPTB -A INPUT -p tcp -m multiport --dports smtp,... -j ACCEPT

Unfortunately, I can't reproduce this in a controlled environment. My
test connections using telnet and netcat go through normally and it
appears some mail is in fact normally delivered. Other IPv4 TCP services
on the same host (e.g. ssh) do not seem affected. I also saw no IPv6
connections with this problem. I'm using Exim MTA (which was not
upgraded recently and it's probably not relevant).

The following quick fix appeared to work around the problem:

iptables -I OUTPUT 1 -p tcp --sport smtp -j ACCEPT

I later reverted back to kernel 3.16.39-1+deb8u2. This also apparently
fixed the problem (I see no more blocked packets).

I see some entries for netfilter in the linux-image changelog, but none
seem particularly relevant:

    - netfilter: restart search if moved to other chain
    - netfilter: nft_exthdr: Add size check on u8 nft_exthdr attributes
    - netfilter: nf_tables: validate maximum value of u32 netlink attributes
    - netfilter: nf_tables: underflow in nft_parse_u32_check()
    - netfilter: nf_conntrack_sip: extend request line validation
    - netfilter: nf_tables: fix type mismatch with error return from
    - netfilter: nf_tables: destroy the set if fail to add transaction
    - netfilter: arp_tables: fix invoking 32bit "iptable -P INPUT ACCEPT"
    - netfilter: rpfilter: fix incorrect loopback packet judgment
    - netfilter: nft_log: restrict the log prefix length to 127

I would appreciate any help how to debug this. The firewall config on
this host is quite old, but as far as I can see, it should still work
with the latest kernel.

I don't want to file a bug at the moment, since I can't reproduce the
problem. But relationship between kernel upgrades and downgrades and the
appearance of dropped SYN-ACK packets in the log seem very clear.

Best regards

Attachment: signature.asc
Description: OpenPGP digital signature

Reply to: