Re: order of netfilter hooks and check for martian source

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 : [email protected], [email protected], [email protected]
Address: Wigner Research Centre for Physics
         H-1525 Budapest 114, POB. 49, Hungary