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
