All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pablo Neira Ayuso <pablo@netfilter.org>
To: "Nirgal Vourgère" <contact_vgernf@nirgal.com>
Cc: Balazs Scheidler <bazsi77@gmail.com>, netfilter@vger.kernel.org
Subject: Re: Fwd: Issue migrating "iptables -m socket --transparent" into nftables
Date: Wed, 19 Aug 2020 09:58:32 +0200	[thread overview]
Message-ID: <20200819075832.GA3994@salvia> (raw)
In-Reply-To: <32610365.DCq6cjG4UW@deimos>

[-- Attachment #1: Type: text/plain, Size: 2276 bytes --]

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.

[-- Attachment #2: x.patch --]
[-- Type: text/x-diff, Size: 1737 bytes --]

diff --git a/include/uapi/linux/netfilter/nf_tables.h b/include/uapi/linux/netfilter/nf_tables.h
index 42f351c1f5c5..fed3514395a5 100644
--- a/include/uapi/linux/netfilter/nf_tables.h
+++ b/include/uapi/linux/netfilter/nf_tables.h
@@ -1008,10 +1008,12 @@ enum nft_socket_attributes {
  *
  * @NFT_SOCKET_TRANSPARENT: Value of the IP(V6)_TRANSPARENT socket option
  * @NFT_SOCKET_MARK: Value of the socket mark
+ * @NFT_SOCKET_WILDCARD: Socket listener is bound to any address
  */
 enum nft_socket_keys {
 	NFT_SOCKET_TRANSPARENT,
 	NFT_SOCKET_MARK,
+	NFT_SOCKET_WILDCARD,
 	__NFT_SOCKET_MAX
 };
 #define NFT_SOCKET_MAX	(__NFT_SOCKET_MAX - 1)
diff --git a/net/netfilter/nft_socket.c b/net/netfilter/nft_socket.c
index 637ce3e8c575..7511640e513a 100644
--- a/net/netfilter/nft_socket.c
+++ b/net/netfilter/nft_socket.c
@@ -14,6 +14,23 @@ struct nft_socket {
 	};
 };
 
+static void nft_socket_wildcard(const struct nft_pktinfo *pkt,
+				struct nft_regs *regs, struct sock *sk,
+				u32 *dest)
+{
+	switch (nft_pf(pkt)) {
+	case NFPROTO_IPV4:
+		nft_reg_store8(dest, inet_sk(sk)->inet_rcv_saddr == 0);
+		break;
+	case NFPROTO_IPV6:
+		nft_reg_store8(dest, ipv6_addr_any(&sk->sk_v6_rcv_saddr));
+		break;
+	default:
+		regs->verdict.code = NFT_BREAK;
+		return;
+	}
+}
+
 static void nft_socket_eval(const struct nft_expr *expr,
 			    struct nft_regs *regs,
 			    const struct nft_pktinfo *pkt)
@@ -59,6 +76,13 @@ static void nft_socket_eval(const struct nft_expr *expr,
 			return;
 		}
 		break;
+	case NFT_SOCKET_WILDCARD:
+		if (!sk_fullsock(sk)) {
+			regs->verdict.code = NFT_BREAK;
+			return;
+		}
+		nft_socket_wildcard(pkt, regs, sk, dest);
+		break;
 	default:
 		WARN_ON(1);
 		regs->verdict.code = NFT_BREAK;
-- 
2.20.1


  reply	other threads:[~2020-08-19  7:58 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CAKcfE+ZhO2O6nanU=ABJB8ptpB8VvjCK1wmzQ8TMFx+U-0_8nw@mail.gmail.com>
     [not found] ` <CAKcfE+anbh1OoHt7vgyYRt89J-fjsKK48Fzy8SCm3RP=HQQcOw@mail.gmail.com>
2020-08-18 11:08   ` Fwd: Issue migrating "iptables -m socket --transparent" into nftables Nirgal Vourgère
2020-08-19  7:58     ` Pablo Neira Ayuso [this message]
     [not found]       ` <CAKcfE+Yyo-zj9Oxh4Oth6yK7SoXVfa2mQrK9-11Q5NHc09uXzQ@mail.gmail.com>
2020-08-21 15:23         ` Pablo Neira Ayuso
2020-08-21 20:10           ` Nirgal Vourgère
2020-08-22  1:24             ` Nirgal Vourgère
     [not found]               ` <CAKcfE+ZHch0LH79Mi2NMM9z4UaoORb09oPur8xrPaK-7F3SRpg@mail.gmail.com>
2020-08-25  9:45                 ` Balazs Scheidler
2020-08-26 18:00                   ` Nirgal Vourgère

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200819075832.GA3994@salvia \
    --to=pablo@netfilter.org \
    --cc=bazsi77@gmail.com \
    --cc=contact_vgernf@nirgal.com \
    --cc=netfilter@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.