On 22.06.2025 13:10, Jozsef Kadlecsik wrote:
You have got a non-simple routing configuration and reverse path filtering
has got its own troubles with it, which is further complicated by natting.
Exactly the same issue happens when one tries to redirect packets to a
service (eg, a transparent proxy) running on 127.0.0.1, - it does not
involve any complex routing setup, and it also fails with current order
of things.
So it's best to separate the issues:
reverse path filtering: By enablink loose mode for both of the default
route interfaces should be enough because that way the routing engine can
find an entry in the FIB and won't drop the packets as martian.
Why can't netfilter dnat hook up AFTER martians check in network stack?
Yes, this requires separation of checking for martians (rp-filter) and
actual routing, but these are separate anyway, since they check for
different things (rp-filter is applied to source address of the incoming
packet, while routing is applied to destination). Wouldn't this solve
this issue once and for all?
Due to NAT, wrong interface picked by the routing engine: you have got
source-based routing which don't play well with NAT. Therefore I suggested
marking and using a mark-based routing because that solves it, both in the
case of iptables and nftables.
I don't see a way to do that. Because autoatic marking reply packets is
- apparenty - done at the same stage as de-DNAT-ification of these
packets, ie, too late, when routing decision has already been done.
No matter what, I don't see how to change the order of netfilter hook
vs routing of the reply packets.
If you can pick another IP address which
matches the good entry in the routing table, that's also good. There's
third solution if you use nftables: the reverse direction for DNAT is an
internal SNAT and in nftables you *can* set the SNAT priority to the same
as DNAT, i.e. before routing. That way routing'll see the natted source
address and source-based routing can pick the good outgoing interface.
However, if you use SNAT as well otherwise, then that can also be affected
in routing.
How one would change the internal SNAT priority so it's applied after or
before routing?
Can't the same mechanism be used to modify priority of regular dnat vs
rp-filter?
[Personally, I always check ingress-egress in netfilter, regardless of the
reverse path filtering.]
Yeah, I'm slowly going towards this direction as well, - but more
because of the current issues with netfilter I'm facing.
Thanks,
/mjt
