Re: order of netfilter hooks and check for martian source
Michael Tokarev <[email protected]> Sat, 21 Jun 2025 20:56:11 +0300
| Newsgroups | gmane.comp.security.firewalls.netfilter.general |
|---|---|
| Message-ID | <[email protected]> |
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. Thanks, /mjt