On 10/10/2018 01:47 PM, David Hobach wrote:
On 10/10/18 3:33 PM, unman wrote:
On Wed, Oct 10, 2018 at 03:17:47PM +0200, Illidan Pornrage wrote:
On 10/10/18 3:14 PM, unman wrote:
On Tue, Oct 09, 2018 at 09:18:22PM +0300, Ivan Mitev wrote:
On 10/9/18 7:44 PM, mfreemon wrote:
On 10/8/18 10:56 AM, mfreemon wrote:
On 10/2/18 2:25 AM, Ivan Mitev wrote:
On 10/2/18 1:32 AM, Chris Laprise wrote:
On 10/01/2018 05:48 PM, mfreemon wrote:
On 1/11/18 3:01 PM, Chris Laprise wrote:
> On 01/10/2018 03:47 PM, Connor Page wrote:
>> The official templates use nftables so shouldn’t be
iptables. I didn’t have time to learn about nftables, so just
nftables package from debian 9 template. YMMV.
> Hmmm, I was just thinking how Qubes' own guest scripts
> iptables even in fedora-26.
> IIUC, iptables and nft are two different interfaces
to netfilter. I
> don't know if it really matters, at least for the R4.0
> prefer to put the syntax change (for docs) off until
a later release.
I was recently thrown by the mix of both nftables and iptables
The qubes docs don't clarify much. The qubes firewall scripts
nft. Most of the discussion on the qubes website documentation is
about iptables, but there are also a few mentions of nft. The
instructions (going from R3.2 to R4) did not mention
from iptables to nftables. It looks like other related
example is qubes-tunnel) is using iptables.
Just reading a few things and trying to come up to speed, I
impression that nftables and iptables should not both by used
same time. Even if technically possible (i.e. both sets of rules
applied correctly), it strikes me as not a great idea to maintain
packet filtering rules in two different ways.
What is the best practice recommendation on this (for R4,
template)? Are we to be using, exclusively, nftables in R4?
The last I read about this (for 4.0) is that nftables is used
Qubes code, but Debian Qubes is still using iptables. That
to be the case since nftables is not installed in my
I've submitted qubes-tunnel to Qubes with iptables commands
the intention to transition to nftables (or that other new
Linux, name escapes me just now) for Qubes 4.1. Someone who is
starting a project might be better off going with nftables.
... until yet another packet filtering mechanism replaces
that case, bpfilter ).
I understand the rationale behind using nftables  but given
how it is
widespread (hint: close to 0 even amongst seasoned sysadmins)
wasn't worth it. The OP's post confirms there's quite some
about how it interacts with iptables, and the official
far from helpful.
I'm quite proficient with iptables and networking in general but
me half an hour to understand how to tweak Qubes' nftables rules
time I wanted to change something in the firewall, while I would
done that task in less than one minute with iptables. I could
a few hours learning nftables to improve the official doc but at
I prefer to spend time learning tech that significantly improves
(eg. Qubes OS over standard linux distribution) over loosing time
learning stuff that is only marginally better.
Anyway - I digress :)
I'm concerned about the confusion and unnecessary complexity here.
Network packet filtering is certainly (one of) those features that
software such Qubes needs to be solid on (in both design approach
and implementation detail).
Is the Qubes team confident in the current situation, such that
users of Qubes should not be concerned?
nb. This is not meant to be a criticism at all. I very much
appreciate the hard (and complicated) work going into Qubes. I'm
just looking to understand the current situation better so as to
judge whether my concern is warranted or not.
As an example: I'm wanting to enable some specific network traffic
between two qubes. The docs say to use iptables
qubes-firewall-user-script also specifies iptables rules. But
qvm-firewall implements the rules it manages using nftables. So the
firewall VMs have both iptables rules and nftables rules in
these are different sets of rules. It's not that the iptables
and the nft command are just two user interfaces showing the same
filtering rules. They are different packet filtering rules. This
like a receipt for disaster.
Is this the wrong forum for this discussion? Should this be on
qubes-devel, or an issue in qubes-issues at
You'll definitely get more visibility on qubes-devel.
FWIW I'm not concerned about the complexity itself: I trust the
not to mess up.
IMHO the problem is that people proficient with iptables are not
spend time learning yet another packet filter tool when iptables
99.99% of the cases (+, as others pointed out, nftables is still
complete wrt. iptables). For those users - an overwhelming majority
nftables firewall is a black box that is difficult to
I think this is the problem. I remember stalwarts hanging on to
for similar reasons. (I speak as someone who has clung on to
far too long.)
It seems to me that the few features lacking in nftables are only of
interest to people who are fully capable of learning a new tool. The
extras that nft brings completely outweigh the deficiencies.
nft provides tools to translate your iptables rules in to the new
syntax, so there's really no excuse for not diving in. Even if you have
minimal time, you can write your iptables rules and then translate them
Qubes tries to provide a straightforward experience for relatively
inexperienced users, and the nft/iptables mix per distribution is a
compromise to that end.
The docs need to be updated to provide nft rules throughout.
^ So do I need to set rules in both or just one of them?
I dont recommend mixing them for clarity.
I would use nft throughout.
If I recall correctly (and this is what
states, too), nftables were introduced in order to *not be used
manually*. I.e. all users should stick to the GUI, qvm-firewall and
iptables wherever possible. That also explains why there's still a lot
more documentation on iptables topics apart from the historical reason.
Since the Qubes firewall is inherently dynamic (rules added and removed
whenever VMs are started and stopped), user scripts sometimes did
interfere with the dynamic changes resulting in unusable rules or even
security issues. Or simply the question "why did my custom rule xyz
disappear?". So all of these dynamic changes went to nftables in 4.0 and
the iptables rules should remain pretty static during the runtime of a
From my standpoint, the only thing wrong with the R3.x firewall was
that (aside from treating custom/tunnel DNS as alien) there's no best
practice established for setting temporary rules outside the
qubes-firewall-user-script. I now realize that creating/describing such
a best practice would have been _easy_ and curtailed about 70% of the
confusion and mishaps... all that was required was a non-racy way to
restart qubes-firewall with the rule changes and documentation saying
this step is required. If I could make the choice, I'd supply a default
qubes-firewall-user-script that looks for ephemeral rules set in a place
But that's moot and I have to say I also like the R4.0 firewall which
has another way of dealing with that issue.
I think the biggest issue with a transition to nft (besides the
documentation) is the apparent fedora-debian inconsistency. Once debian
has essentially the same nft-based code as fedora then people can choose
their favorite interface without incompatibility worries.
Chris Laprise, tas...@posteo.net
PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886
You received this message because you are subscribed to the Google Groups
To unsubscribe from this group and stop receiving emails from it, send an email
To post to this group, send email to email@example.com.
To view this discussion on the web visit
For more options, visit https://groups.google.com/d/optout.