AIF fails with iptables 1.8.1 about aif

[i00kv6d]

Confirmed!!!
temp solution for version 2.0.1f (debian)

--- arno-iptables-firewall.bak
+++ arno-iptables-firewall
@@ -4535,9 +4535,9 @@
   # Drop outgoing fragmented packets (this should in principle never happen because of netfilter's
   # packet defragmentation
   ################################################################################################
-  ip4tables -A OUTPUT -f \
-    -m limit --limit 3/m -j LOG --log-level $LOGLEVEL --log-prefix "AIF:Fragment packet: "
-  ip4tables -A OUTPUT -f -j DROP
+  #ip4tables -A OUTPUT -f \
+  #  -m limit --limit 3/m -j LOG --log-level $LOGLEVEL --log-prefix "AIF:Fragment packet: "
+  #ip4tables -A OUTPUT -f -j DROP

[abelbeck]

Thanks for the heads-up and fix @i00kv6d . It is like the -f option is ignored in iptables 1.8.x.

The iptables 1.8.0 Changlog: https://netfilter.org/projects/iptables/files/changes-iptables-1.8.0.txt

Florian Westphal (107):
...
xtables-compat: fix ipv4 frag (-f)

http://git.netfilter.org/iptables/commit/?id=de874054ec26a78ce83ccf13c449a4d3c4a5778e

Possibly this is a bug introduced in iptables 1.8.x ?

@arnova thoughts for an AIF fix ?

[i00kv6d]

I think it does not matter 1.6.x or 1.8.x.
The comment says:
"this should in principle never happen because of netfilter's packet defragmentation"

IMHO redundant code. Need to delete.

[abelbeck]

FYI, Netfilter Docs on "Specifying Fragments"

https://www.netfilter.org/documentation/HOWTO//packet-filtering-HOWTO-7.html#ss7.3

Specifying Fragments
Sometimes a packet is too large to fit down a wire all at once. When this happens, the packet is divided into fragments, and sent as multiple packets. The other end reassembles these fragments to reconstruct the whole packet.

The problem with fragments is that the initial fragment has the complete header fields (IP + TCP, UDP and ICMP) to examine, but subsequent packets only have a subset of the headers (IP without the additional protocol fields). Thus looking inside subsequent fragments for protocol headers (such as is done by the TCP, UDP and ICMP extensions) is not possible.

If you are doing connection tracking or NAT, then all fragments will get merged back together before they reach the packet filtering code, so you need never worry about fragments.

Please also note that in the INPUT chain of the filter table (or any other table hooking into the NF_IP_LOCAL_IN hook) is traversed after defragmentation of the core IP stack.

Otherwise, it is important to understand how fragments get treated by the filtering rules. Any filtering rule that asks for information we don't have will not match. This means that the first fragment is treated like any other packet. Second and further fragments won't be. Thus a rule -p TCP --sport www (specifying a source port of `www') will never match a fragment (other than the first fragment). Neither will the opposite rule -p TCP --sport ! www.

However, you can specify a rule specifically for second and further fragments, using the -f' (or --fragment') flag. It is also legal to specify that a rule does not apply to second and further fragments, by preceding the -f' with ! '.

Usually it is regarded as safe to let second and further fragments through, since filtering will effect the first fragment, and thus prevent reassembly on the target host; however, bugs have been known to allow crashing of machines simply by sending fragments. Your call.

Note for network-heads: malformed packets (TCP, UDP and ICMP packets too short for the firewalling code to read the ports or ICMP code and type) are dropped when such examinations are attempted. So are TCP fragments starting at position 8.

[i00kv6d]

OK.
I tried the example from https://www.netfilter.org/documentation/HOWTO//packet-filtering-HOWTO-7.html#ss7.3
Used a different destination address. In version 1.6.0 and 1.8.1 the rule works.
Removed the destination address from the rule and in version 1.8.1 the rule does not work as expected!
Is the destination address required in 1.8.1?

[abelbeck]

Does specifying a destination -d 0.0.0.0/0 work with 1.8.1 ?

[i00kv6d]

Does specifying a destination -d 0.0.0.0/0 work with 1.8.1 ?

doesn't work.

But is -d 0.0.0.0/0 and not specifying the destination address is not the same?

[abelbeck]

But is -d 0.0.0.0/0 and not specifying the destination address is not the same?

Yes it should, just trying to isolate where the problem may be ... @i00kv6d thanks for testing

[arnova]

I have confirmation from the guys over at netfilter/iptables that it's a regression in iptables which should be fixed in 1.8.2

[arnova]

See https://git.netfilter.org/iptables/commit/?id=05947c82232e3a3d20f93a1ba18e35e7f4e23671

[i00kv6d]

Confirmed!!!
Version 2.0.1f (debian) with iptables 1.8.2 (package own build) is working.

[arnova]

Thanks for reporting back