From: Wilmer van der Gaast <wilmer@gaast.net>
To: Pablo Neira Ayuso <pablo@netfilter.org>, netfilter-devel@vger.kernel.org
Subject: Re: Mixed IPv4+IPv6 sets
Date: Wed, 09 Sep 2015 11:07:08 +0100 [thread overview]
Message-ID: <55F004CC.2080207@gaast.net> (raw)
In-Reply-To: <20150907185025.GB17921@salvia>
On 07-09-15 19:50, Pablo Neira Ayuso wrote:
>
> Could you illustrate with examples what you would like to have and the
> limitations you currently hitting?
>
So what I was trying to do is define sets with my local + trusted
networks. So for example:
define local = {
192.168.0.0/24,
2001:888:1001:1::/64,
}
define trusted = {
$local
87.198.233.214,
2001:888:1001::/48,
}
So I'd use these as whitelists, could use $trusted as a wider whitelist
for all my networks and $local as just for completely local traffic.
Containing IPv4 and IPv6 addresses/networks.
Now I'd love to be able to just, for example (and apologies for the
likely wrong syntax, I have not been able to start using nftables in
full, just experimenting):
table inet filter {
chain forward {
type filter hook forward priority 0;
...
# (Mostly) don't filter traffic from my trusted nets
inet saddr $trusted accept;
# Filter the rest more strictly.
...
}
}
This won't work because inet is not an existing match rule. I can have
an "inet" table but it still needs to have ip and ip6 match rules
separately. It is nice that many other rules just work like for example
tcp/udp and ct.
Now if I could just do:
# (Mostly) don't filter traffic from my trusted nets
ip saddr $trusted accept;
ip6 saddr $trusted accept;
somehow and have nft take just the v4 and just the v6 addresses for each
line, that would also be workable. Or what I tried doing (but then I ran
into the crash bug I've just reported), is separate the two whitelists
completely and do:
# (Mostly) don't filter traffic from my trusted nets
ip saddr $trusted4 accept;
ip6 saddr $trusted6 accept;
The latter would work and is not bad, just kludgy. Being able to just
refer to a single mixed set of addresses from a single rule would
certainly be the most convenient, as one more step towards fully
unifying IPv4 + IPv6 filtering.
Kind regards,
Wilmer van der Gaast.
--
+-------- .''`. - -- ---+ + - -- --- ---- ----- ------+
| wilmer : :' : gaast.net | | OSS Programmer www.bitlbee.org |
| lintux `. `~' debian.org | | Full-time geek wilmer.gaast.net |
+--- -- - ` ---------------+ +------ ----- ---- --- -- - +
prev parent reply other threads:[~2015-09-09 10:07 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-06 18:52 Mixed IPv4+IPv6 sets Wilmer van der Gaast
2015-09-07 18:50 ` Pablo Neira Ayuso
2015-09-08 8:21 ` Arturo Borrero Gonzalez
2015-09-09 10:08 ` Wilmer van der Gaast
2015-09-09 10:07 ` Wilmer van der Gaast [this message]
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=55F004CC.2080207@gaast.net \
--to=wilmer@gaast.net \
--cc=netfilter-devel@vger.kernel.org \
--cc=pablo@netfilter.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.