On Tue, Aug 18, 2020 at 01:08:43PM +0200, Nirgal Vourgère wrote:
> On Tuesday, 18 August 2020 11:18:50 CEST Balazs Scheidler wrote:
> >> Does any one know the proper equivalent to
> >>     iptables -t mangle -A PREROUTING -m socket --transparent -j MARK --set-mark 1
> >> using nft?
> >
> > The original iptables "socket" match had an extra check so that it wouldn't
> > match listener sockets, at least by default (that is if --nowildcard is not
> > specified).
> > 
> > I don't see however how "outbound masqueraded connection" could be
> > impacted. The "socket transparent 1" expression should require that the
> > socket being matched has IP_TRANSPARENT setsockopt set. Are those
> > connections also initiated by haproxy?
> > 
> > In any case, I think the check to ignore wildcard bound listener sockets is
> > definitely missing, however I am not sure how to properly add it to
> > nftables. If I added it to the socket match implementation that might break
> > a few currently well behaving use-cases. @pablo@netfilter.org
> > <pablo@netfilter.org> can you please advise? This is the check that is in
> > iptables -m socket:
> > 
> >                 wildcard = (!(info->flags & XT_SOCKET_NOWILDCARD) &&
> >                             sk_fullsock(sk) &&
> >                             inet_sk(sk)->inet_rcv_saddr == 0);
> > 
> > And then if --transparent is used, these sockets are not accepted / the
> > rule does not match.
> 
> That's it I guess:
> 
> I tried adding --nowildcard to my working iptables rules and I got the same error, https connections from the lan side are not masqueraded toward the wan, but routed locally to the socket listening to *:443.
> (thanks tcptraceroute for the info)
> 
> So basically
>     nft > socket transparent 1 meta mark set 1
> may be the equivalent of
>     iptables > -m socket --transparent --nowildcard -j MARK --set-mark 1
> while I'm looking for *not* having "--nowildcard".
> 
> Any idea about how work around this? I was thinking of using the
> "fib" rules to match the wan side packets since they have a
> destination ip address that match one of the local address, while
> the wan bound packets don't.

I'll post this patch to netfilter-devel to add the missing logic.