Re: [PATCH net] netfilter: nf_dup_netdev: scrub duplicates to preserve the direct path

[Pablo Neira Ayuso <pablo@netfilter.org>]

Hi,

On Wed, Aug 12, 2026 at 01:19:07AM +0200, Alexandre Ferrieux wrote:
> Hi,
> 
> >> On Tue, Aug 04, 2026 at 10:11:50PM +0200, Alexandre Ferrieux wrote:
> >>>
> >>> In other words, the "dup" path has the potential to wreak havoc
> >>> in the direct path as a consequence of secondary link failures. This
> >>> is very bad behavior for a monitoring tool, which is the most
> >>> obvious application of 'dup'.
> >>
> >> Can you describe your use-case a bit and how it breaks?
> > Sure:
> > 
> >  - assume hosts A.eth0 and B.eth0 have active production traffic (say TCP)
> >  - assume we have a monitoring tool on A that dups eth0's egress to some other
> > interface $MON
> > 
> >     nft add chain netdev ta ch '{type filter hook egress device "eth0" priority
> > filter ; policy accept ; }'
> >     nft add rule netdev ta ch dup to $MON
> > 
> >  - assume something goes wrong on $MON generating link failures. In my case it
> > was a GRETAP with L3 destination suddenly unreachable.
> > 
> >  - The next A->B packet goes through normally, but its duplicate hits
> > ipv4_link_failure(), hence the dst (which is B) is expired.
> > 
> >  - As a result, (say) TCP disruptions occur. The thermometer killed the patient :)
> > 
> > Note: as a straightforward repro, you can simply witness "noise" in simple ping
> > sessions, with ghost unreach reports muxed with normal measurement:
> > 
> >     ip link add gre1 type gretap remote 192.168.1.99 ;# on the LAN, nonexistent
> > IP => will generate link failures
> >     ip link set dev gre1 up
> >     nft add table netdev ta
> >     nft add chain netdev ta ch '{type filter hook egress device "eth0" priority
> > filter ; policy accept ; }'
> >     nft add rule netdev ta ch counter dup to gre1
> >     ping -n 8.8.8.8
> >  =>
> >     PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
> >     64 bytes from 8.8.8.8: icmp_seq=1 ttl=115 time=19.9 ms
> >     64 bytes from 8.8.8.8: icmp_seq=2 ttl=115 time=12.8 ms
> >     64 bytes from 8.8.8.8: icmp_seq=3 ttl=115 time=36.0 ms
> >     64 bytes from 8.8.8.8: icmp_seq=4 ttl=115 time=30.3 ms
> >     From 192.168.1.13 icmp_seq=5 Destination Host Unreachable
> >     64 bytes from 8.8.8.8: icmp_seq=5 ttl=115 time=31.0 ms
> >     From 192.168.1.13 icmp_seq=6 Destination Host Unreachable
> >     64 bytes from 8.8.8.8: icmp_seq=6 ttl=115 time=38.0 ms
> >     From 192.168.1.13 icmp_seq=7 Destination Host Unreachable
> >     64 bytes from 8.8.8.8: icmp_seq=7 ttl=115 time=36.8 ms
> >     From 192.168.1.13 icmp_seq=8 Destination Host Unreachable
> >     64 bytes from 8.8.8.8: icmp_seq=8 ttl=115 time=23.5 ms
> >     ^C
> > 
> > 
> >>
> >>> This patch fixes all similar scenarii by calling skb_scrub_pkt()
> >>> on the clone, severing its link to precious direct-path state.
> >>
> >> This patch is targetted at the net tree, but nf.git is preferred.
> > Okay, will retarget :)
> > 
> >> As for the conntrack and dst, you have to explain what it breaks on
> >> your end.
> > Dst as shown above. Conntrack is more speculation, but my take is that in any
> > case the dup path should *never* have any kind of retroaction on the observed
> > path, so any "complex state" attached to the direct path should be absolutely
> > isolated from "whatever happens on the dup path". Am I mistaken ?
>
> What do you think ? Is the description of the problem satisfactory ? Is the
> proposed solution acceptable ?

I think conntrack should be set to untracked for the dup.

And dst should be resetted if skb_valid_dst() returns true, so
DST_METADATA can still be processed for duplicated packets.