Re: Fwd: Issue migrating "iptables -m socket --transparent" into nftables

[Balazs Scheidler <bazsi77@gmail.com>]

On Sat, Aug 22, 2020 at 08:45:22AM +0200, Balazs Scheidler wrote:
> hmm.. judging the code alone, I can't see the difference between xt_socket
> and nft_socket, they are checking the same things for ipv6.
> 
> I am not sure when sk->sk_v6_rcv_saddr is properly set, if that's non-zero
> we would yield "socket wildcard 0" and cause a match.
> 
> I can see that __inet6_bind() sets this properly, so as long as haproxy
> binds it to port 80/443 we should be fine.
> 
> I still cannot get what you mean under "But ipv6 outbound connections still
> are grabbed by the socket rather than be routed to the wan and
> masqueraded." exactly.
> 
> 1) haproxy binds to [::0]:80 and I assume it does that to receive external
> traffic. Do you use tproxy rules to redirect traffic here?
> 2) then haproxy would establish a connection from [clientip]:randomport ->
> internal server:80. The return traffic should be matched by "socket
> transparent 1 socket wildcard 0" and redirected as such.
> 
> So which of the two connections above is what you mean?

The question still stands, which of the two connection is getting the wrong
treatment?

@Pablo: do you want me to test/push the kernel piece to netfilter-devel?
Also, I have a usability question in the email I sent there.

Hopefully, by now I can send email to vger :)

Cheers,
-- 
Bazsi