Linux Netfilter discussions
 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox