nf_nat_icmp_reply_translation dropped icmp redirect packet

[sun miller <sunminlei@xxxxxxxxx>]

Hello,

I've noticed an issue during my testing, and I believe I've identified
the root cause in the code. However, I'm not sure if it's a bug or a
deliberate feature.

Here's the testing process:

1. When a request (src: A, dst: B) is sent to the machine (R) for some
reason. R has ip_forward enabled (echo 1 >
/proc/sys/net/ipv4/ip_forward).   // A, B, and R are in the same
subnet.

2. When there's no firewall enabled, R sends an ICMP redirect packet to A.

3. When the firewall is enabled, R doesn't send an ICMP redirect
packet to A   // tcpdump -i any icmp -nn shows no packet

I've traced the code path as follows:

1. ip_rcv --> nf_hook_slow (PREROUTING) --> ... -->
nf_nat_alloc_null_binding --> nf_nat_setup_info // ct->status = 256
2. ip_rcv_finish --> ip_forward --> ip_rt_send_redirect --> icmp_send
--> icmp_push_reply --> ... --> nf_conntrack_attach // nskb ct->status
= 256
3. then,  icmp_push_reply --> ip_push_pending_frames --> ... -->
iptable_nat_ipv4_local_fn (OUTPUT) --> nf_nat_ipv4_fn -->
nf_nat_icmp_reply_translation

Here's the relevant code:


int nf_nat_icmp_reply_translation(...)
{
    // ...
    inside = (void *)skb->data + hdrlen;
    if (inside->icmp.type == ICMP_REDIRECT) {
        // ct->status is 256, but IPS_NAT_DONE_MASK is 384
        if ((ct->status & IPS_NAT_DONE_MASK) != IPS_NAT_DONE_MASK)
            return 0;
    // ...
}

unsigned int nf_nat_ipv4_fn(...)
{
    // ...
    switch (ctinfo) {
    case IP_CT_RELATED:
    case IP_CT_RELATED_REPLY:
        if (ip_hdr(skb)->protocol == IPPROTO_ICMP) {
            if (!nf_nat_icmp_reply_translation(skb, ct, ctinfo, ops->hooknum))
                return NF_DROP;   //  <------- DROP
            else
                return NF_ACCEPT;
        }
    // ...
}


Because PREOUTING and OUTPUT have the same maniptype
(NF_NAT_MANIP_DST), ct->status can't equal IPS_NAT_DONE_MASK.

I've tested this on multiple kernel versions, including 3.10, 5.15,
and 6.5, and I can reproduce the issue.

Currently, I'm unsure if this is a bug or an intentional feature. If
it's a feature, where can I find reference documentation that explains
this behavior?