On Sat, 21 Jun 2025, Michael Tokarev wrote:
> On 21.06.2025 20:50, Michael Tokarev wrote:
> > On 21.06.2025 19:08, Michael Tokarev wrote:
> > > On 21.06.2025 19:05, Jozsef Kadlecsik wrote:
> > > > On Sat, 21 Jun 2025, Michael Tokarev wrote:
> > > >
> > > > > On 21.06.2025 17:42, Jozsef Kadlecsik wrote:
> > > > > ..
> > > > > > However, routing decisions can be affected by marking packets. So
> > > > > > I'd mark
> > > > > > packets before routing and use routing tables according to the mark
> > > > > > value.
> > > > >
> > > > > The prob with replies to DNAted packets is that these packets traverse
> > > > > routing rules first, BEFORE they're seen by netfilter code. Who can
> > > > > mark them for routing if routing is done before it's in netfilter?
> > > >
> > > > No, not at all. You can mark the incoming first packet, store the
> > > > packet's mark value in conntrack and restore from conntrack for
> > > > the reply packets in mangle/prerouting. Which is exactly that,
> > > > before routing.
> >
> > I tried to follow this route. In the dnat rule, I applied a mark to
> > this conntrack entry, and checked this fwmark in ip rule to perform
> > routing through ip2/gw2 instead of default ip1/gw1.
>
> I figured out how to actually make it work. I can dnat the initial
> packet to a different internal-host IP (adding second IP to the dnat
> destination host), and in the routing rules, use this second IP as
> the key for routing table decision. Thankfully there's no shortage
> for internal IP addresses. But this is very ugly, - an ugly work-
> around for a bug in kernel which shouldn't be there in the first
> place.
>
> For the initial issue (martians checked after netfilter doing mangling),
> the work-around also exists and is also really ugly - it is repeating
> the martians check in netfilter rules, ie, keeping routing table in two
> places.
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.
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.
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. 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.
[Personally, I always check ingress-egress in netfilter, regardless of the
reverse path filtering.]
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
