On Fri, 13 Sept 2024 at 16:18, Florian Westphal <fw@xxxxxxxxx> wrote: > > Pablo Neira Ayuso <pablo@xxxxxxxxxxxxx> wrote: > > > Hmm. Looking at nft_nat.c, 'accept' seems consistent with what nat > > > statements do implicitly. > > > > Yes, and xt_TPROXY does NF_ACCEPT. > > > > On the other hand, I can see it does NF_DROP it socket is not > > transparent, it does NFT_BREAK instead, so policy keeps evaluating the > > packet. > > Yes, this is more flexible since you can log+drop for instance in next > rule(s) to alert that proxy isn't running for example. > This is super useful, in the scenario that the transparent proxy takes over the DNATed virtual IP, if the transparent proxy process is not running the packet goes to the DNATed virtual IP so the clients don't observe any disruption. > > > > is this sufficient in your opinion? If so, I made this quick update > > > > for man nft(8). > > > > > > Acked-by: Phil Sutter <phil@xxxxxx> > > > > > > In addition to that, I will update tproxy_tg_xlate() in iptables.git to > > > emit a verdict, too. > > > > Thanks, this is very convenient. > > Agreed, it should append accept keyword in the translator. I'm not completely following the technical details sorry. With my current configuration I do set an accept action udp dport 53 tproxy ip to 127.0.0.1:46659 accept and I have dnat statements after that action. The packet is "proxied" but "nftrace monitor" shows that the subsequent rules are evaluated and I also can observe that the NAT entries are added on the conntrack table despite the packet being proxied. I think that there has to be a way to indicate that after some point the subsequent rules can not take actions, per example, the conntrack entries generated by the DNAT rules, at least with UDP, interfere with subsequent packets .
