On Sun, 22 Jun 2025, Michael Tokarev wrote:
> 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.
That is also a case when routing and NAT-ing don't play well.
> > 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?
I can repeat only myself: routing is a whole system, independent of the
netfilter framework. We can't pick parts of it or jump into a specific
stage.
> > 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.
Where comes this "apparently"? There's no automatic packet marking,
at all. You tell the system at exactly when should it happen. In
iptables-save language, mark value 1 for original direction, mark 2 for
reply
*filter
...
# Original direction
# In nftables it's not needed but in iptables
# we don't have multiple targets
:mark-accept - [0:0]
-A mark-accept -j CONNMARK --mark 1
-A mark-accept -j LOG/ULOG ...
-A mark-accept -j ACCEPT
# Original direction, first packet
... -m state --state NEW ... -j mark-accept
# Reply direction
*mangle
...
-A PREROUTING -m state --ctdir REPLY -m connmark --mark 1 -j MARK --mark 2
> How one would change the internal SNAT priority so it's applied after or
> before routing?
table ip nat {
chain postrouting {
# Override default priority and set it before routing
type nat hook postrouting priority dstnat; policy accept;
}
chain prerouting {
type nat hook prerouting priority dstnat; policy accept;
}
}
See https://wiki.nftables.org/wiki-nftables/index.php/Netfilter_hooks
> Can't the same mechanism be used to modify priority of regular dnat vs
> rp-filter?
With the above SNAT happens before routing, including rp-filter.
Best regards,
Jozsef
--
E-mail : kadlec@xxxxxxxxxxxxx, kadlec@xxxxxxxxxxxxxxxxx, kadlecsik.jozsef@xxxxxxxxx
Address: Wigner Research Centre for Physics
H-1525 Budapest 114, POB. 49, Hungary
