[libvirt-users] Best practice for custom iptables rules

[Laine Stump]

On 01/09/2014 12:38 PM, ZeroUno wrote:
> Il 08/01/14 16:17, Laine Stump ha scritto:
>
>> On 01/08/2014 01:43 PM, ZeroUno wrote:
>>> Also, regarding the "iptables restart problem" described in the last
>>> paragraph at <http://libvirt.org/firewall.html>, is there really no
>>> acceptable way to make libvirt add its rules back automatically upon
>>> iptables/network restart?
>>
>> Take a look at this, it may help you:
>>
>>    
>> http://wiki.libvirt.org/page/Networking#Forwarding_Incoming_Connections
>
> Uhm, apart from the fact that the page clearly states this is a
> "hack", so it's far from being a best practice (although surely easy
> and interesting!),

you asked for "best", not "ideal" :-) Aside from eliminating all use of
libvirt-created networks and instead manually setting up the bridge,
iptables rules, and dnsmasq yourself in the host system config, that
really is currently the "best" way of achieving what you want.


> AFAICT this might help with adding rules to the NAT table, which was
> the first part of my question, but does not help with the network
> restart issue because hook scripts are only called upon libvirt
> events: libvirt daemon start/stop, guest start/stop...
>
> Did I understand correctly?

Correct. The problem the paragraph that you referenced is referring to
is caused by the lack of a central authority/controller for managing
iptables rule addition/removal requests from multiple
applications/services. and that's not a problem that libvirt is able to
solve by itself. But that same paragraph also tells you how to have the
iptables service signal libvirt to reload its iptables rules.
Alternately, the better solution to this problem is firewalld - if your
system uses firewalld, then libvirt is listening for firewalld events on
dbus, and will automatically reload its rules anytime firewalld restarts.

>
>> (Recently libvirt gained the ability for an application to register
>> functions that will be called when a network is
>> defined/undefined/started/stopped, but using that would require an
>> application to be running which registered the necessary callback
>> functions; not nearly as simple as stuffing a shell script into
>
> Indeed, looks like this would be overkill for my needs.
>
> Thank you!
>