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

["Nirgal Vourgère" <contact_vgernf@nirgal.com>]

My apologies for the delay.
I ran into an *unrelated* issue, that troubled ipv6 outbound (masqueraded) connections.

I did some more tests with your patches for linux & nftables.

All look good, both ipv4 & v6, for both inbound (redirected to the socket) and outbound (masqueraded) connections.

Thank you again! :)

On Tuesday, 25 August 2020 11:45:30 CEST Balazs Scheidler wrote:
> 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,
>