linux-kernel - Re: [PATCH v3 1/1] nft_ct: Added nfct_seqadj_ext

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CANhDHd_W=FQkm0u3ZBSE4-RQpGQcXUqKwJRDj7e9anPbv8Djrw@mail.gmail.com>
Date: Fri, 24 Oct 2025 14:26:40 +0200
From: Andrii Melnychenko <a.melnychenko@...s.io>
To: Florian Westphal <fw@...len.de>
Cc: Pablo Neira Ayuso <pablo@...filter.org>, kadlec@...filter.org, phil@....cc, 
	davem@...emloft.net, edumazet@...gle.com, kuba@...nel.org, pabeni@...hat.com, 
	horms@...nel.org, netfilter-devel@...r.kernel.org, coreteam@...filter.org, 
	netdev@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 1/1] nft_ct: Added nfct_seqadj_ext_add() for NAT'ed conntrack.

Hi everyone,

On Thu, Oct 23, 2025 at 2:42 PM Florian Westphal <fw@...len.de> wrote:
>
> Andrii Melnychenko <a.melnychenko@...s.io> wrote:
> > I've taken a look at the `nat_ftp` test from nftables. It actually
> > passes fine, I've tried to modify the test, add IPv4 and force
> > PASV/PORT mode - everything works.
> > Currently, I'm studying the difference between NFT rulesets.
> > Primarily, I'm testing on 2 kernels: 6.6.108 and 6.14.0-33.
>
> I think its this:
>     chain POST-srcnat {
>         type nat hook postrouting priority srcnat; policy accept;
>         ip6 daddr ${ip_sr} ip6 nexthdr tcp tcp dport 21 counter snat ip6 to [${ip_rs}]:16500
>     }
>

It is! I've compared the ruleset and found that the SNAT rule differs slightly.
In my case, it's something like this:

```
ip6 daddr ${ip_cr} ip6 nexthdr tcp tcp sport 21 counter snat ip6 to ${ip_rc}
```

So, for example:
 +-------------------+     +----------------------------------+
 | FTP: 192.168.13.2 | <-> | NAT: 192.168.13.3, 192.168.100.1 |
 +-------------------+     +----------------------------------+
                                     |
                         +-----------------------+
                         | Client: 192.168.100.2 |
                         +-----------------------+

The FTP server is "behind" the router. So the client needs to connect
to the router.
With a ruleset like this:

```
table ip nat {
        ct helper ftp_helper {
                type "ftp" protocol tcp
                l3proto ip
        }

        chain prerouting {
                type nat hook prerouting priority dstnat; policy accept;
                tcp dport 21 dnat ip prefix to ip daddr map {
192.168.100.1 : 192.168.13.2/32 }
        }

        chain postrouting {
                type nat hook postrouting priority srcnat; policy accept;
                tcp sport 21 snat ip prefix to ip saddr map {
192.168.13.2 : 192.168.100.1/32 }
        }

        chain filter_prerouting {
                type filter hook prerouting priority 350; policy accept;
                tcp dport 21 ct helper set "ftp_helper"
        }
}
```

Client has to connect to the router (192.168.100.2 -> 192.168.100.2),
while the FTP server would receive the connection from the client
(192.168.100.2 -> 192.168.33.2).
So the connection hits SNAT when it's already established and confirmed.

> This sets up snat which calls nf_nat_setup_info which adds the
> seqadj extension.

So, we still need to add seqadj allocation for DNAT.
I will propose a new patch v4 with `regs->verdict.code = NF_DROP;`.
And later, I can provide a new ruleset for tests in `nft_ftp` for `nftables`.

Any suggestions?

-- 

Andrii Melnychenko

Phone +1 844 980 2188

Email a.melnychenko@...s.io

Website vyos.io

linkedin.com/company/vyos

vyosofficial

x.com/vyos_dev

reddit.com/r/vyos/

youtube.com/@...SPlatform

Subscribe to Our Blog Keep up with VyOS