libvirt users - Jan 2014 - Re: Best practice for custom iptables rules

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!), 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?
> (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!

-- 
01

Il 09/01/14 11:38, ZeroUno ha scritto:
> Il 08/01/14 16:17, Laine Stump ha scritto:
>> http://wiki.libvirt.org/page/Networking#Forwarding_Incoming_Connections
>
> interesting!), AFAICT this might help with adding rules to the NAT
> table, which was the first part of my question, but does not help with
...also, it appears that the hook script /etc/libvirt/hooks/daemon to be 
called when the libvirt daemon is started is actually called _before_ 
libvirt adds its own iptables rules, because I am not able to insert my 
custom rule at the top of the chain.

Maybe I might use the qemu script which is called each time a guest is 
started/stopped, by inserting some checks to prevent duplicates, but it 
becomes even more "hackish"... :)

-- 
01

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!
>

On 01/09/2014 02:07 PM, ZeroUno wrote:
> Il 09/01/14 11:38, ZeroUno ha scritto:
>
>> Il 08/01/14 16:17, Laine Stump ha scritto:
>>>
http://wiki.libvirt.org/page/Networking#Forwarding_Incoming_Connections
>>
>> interesting!), AFAICT this might help with adding rules to the NAT
>> table, which was the first part of my question, but does not help with
>
> ...also, it appears that the hook script /etc/libvirt/hooks/daemon to
> be called when the libvirt daemon is started is actually called
> _before_ libvirt adds its own iptables rules, because I am not able to
> insert my custom rule at the top of the chain.
>
> Maybe I might use the qemu script which is called each time a guest is
> started/stopped, by inserting some checks to prevent duplicates, but
> it becomes even more "hackish"... :)
Interesting point, and one which reinforces the idea that a network
event hook script might be a nice thing to have (although adding in
callout to an externally-created shell script always has security
implications, especially for a process running as root).

Il 09/01/14 13:40, Laine Stump ha scritto:
> you asked for "best", not "ideal" :-) Aside from
eliminating all use of
;)
> solve by itself. But that same paragraph also tells you how to have the
> iptables service signal libvirt to reload its iptables rules.
Sorry, what do you mean? I'm not able to find such an indication in that 
page...

-- 
01

> ...also, it appears that the hook script /etc/libvirt/hooks/daemon to be
> called when the libvirt daemon is started is actually called _before_
> libvirt adds its own iptables rules, because I am not able to insert my
> custom rule at the top of the chain.
>
how about this daemon hook script?

#!/bin/bash
#
insert_rule() {
    sleep 2
    iptables -t nat -D CUSTOM_RULE
    iptables -t nat -I CUSTOM_RULE
}


case $2 in
    start|reload)
        insert_rule  >/dev/null 2>&1 &
        ;;
    *)
        :
        ;;
esac