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 :-/)
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)
3) add a <filter> subelement to <forward> that allows specifying
iptables rules for the network. Perhaps this could instead be a
<filterref>, and use nwfilter to specify the rules? (that sounds really
cool, and if it worked it would be a nice re-use of the nwfilter driver,
but it may have undetermined pitfalls due to nwfilter being designed
with guest traffic filtering in mind, would take a lot more work, and
wouldn't address the most common request - "Don't mess with iptables! I
want to do it myself!".
Anyone have an opinion or alternate idea?
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list