On 04/26/2016 04:15 AM, Daniel P. Berrange wrote:
On Mon, Apr 25, 2016 at 01:48:49PM -0400, Laine Stump wrote:
We still periodically get requests to allow custom iptables rules for
libvirt virtual networks (or, more commonly, a mode where libvirt simply
leaves iptables alone, not adding or removing anything), and it's been a
nagging item on my to-do list for a very long time. The problem is that,
although the amount of code required to support *any* solution is very
small, it's one of those things without a single obvious "only" way to do
it. Anyway, I'm going to take one more stab at it.
First, some background points:
* For <forward mode='nat'> libvirt's iptables rules are essential to the
operation of the forwarding, so we shouldn't mess with that.
* For [no forward mode], libvirt's iptables rules are a part of what keeps
the network isolated from the rest of the network, so we shouldn't mess with
that either.
* For <forward mode='route'> we currently allow all outgoing and incoming as
long as it is to/from the IP address range defined for the network.
So we really want something that can be used only for <forward mode='route'>
I can see 3 different possibilities:
1) a new forward mode which is just like 'route', but doesn't add any
iptables rules. (what to call it though? "filterless-route"? Too long and
ugly :-/)
I'd suggest this and just call it mode='bare' or mode='open', to avoid
implying any specific semantics about the connectivity.
Thinking about this more, I'm having disturbing memories of trying to
combine multiple knobs into a single attribute in the past, only to have
it backfire later (I can't recall anything specific though) - for
example although I say right now that there's no reason to skip adding
rules for isolated or nat networks, we may come up with a valid use case
in the future. For that reason, I think it may be safer to add:
<forward mode='route' filter='none'/>
(or "manual" as Cole suggested). That way it's still obvious from mode
that the traffic will be routed to other networks, and it will be
possible to use the filter attribute for other modes (or add other
filter settings even for mode='route') in the future. (Validation would
be added to make sure that the filter attribute isn't set for any mode
other than route). Does that make sense?
2) a new attribute to <forward> that takes effect only for mode='route'.
Maybe call it "filter". We could have "filter='open'" (what it does
currently, and will remain the default), "filter='outgoingOnly'", and
"filter='none' (the most requested functionality - no iptables rules would
be added for the network)
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list