3

I'm trying to setup some specific IPTables rules on an ubuntu 14.04.1 host that runs some KVM guests.

The box has multiple NICs with multiple IP addresses and the guests use different addresses based on their function.

I normally use iptables-persistent to achieve this, but for some reason, the rules under /etc/iptables/rules.v4 are not being loaded at boot time. iptables-persistent works correctly when libvirt is not installed.

If I run '/etc/init.d/iptables-persistent start' then the rules are loaded and the setup is as I expect. But at boot they are not. I've tried creating a very simple rules.v4 file to debug this, but it is still not loaded.

The init symlink for iptables-persistent exists at /etc/rc2.d/S37iptables-persistent

I have confirmed that ufw is disabled. I have also removed the nwfilter rules from /etc/libvirt/nwfilter and virsh nwfilter-list does not display any entries.

Any idea what else might be setting these rules and how I customise them as I want them ?

ufw status output

# ufw status
Status: inactive

virsh nwfilter-list output

# virsh nwfilter-list
 UUID                                  Name                 
------------------------------------------------------------------

contents of /etc/iptables/rules.v4

*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:LOG_AND_DROP - [0:0]
-A INPUT -s 192.168.10.0/24 -i br0 -j ACCEPT
-A INPUT -s 192.168.11.0/24 -i br0 -j ACCEPT
-A LOG_AND_DROP -j LOG --log-prefix "iptables deny: " --log-level 7
-A LOG_AND_DROP -j DROP
COMMIT

output of iptables -L -n after boot (unwanted result)

# iptables -L -n -v
Chain INPUT (policy ACCEPT 12 packets, 912 bytes)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 ACCEPT     udp  --  virbr0 *       0.0.0.0/0            0.0.0.0/0            udp dpt:53
    0     0 ACCEPT     tcp  --  virbr0 *       0.0.0.0/0            0.0.0.0/0            tcp dpt:53
    0     0 ACCEPT     udp  --  virbr0 *       0.0.0.0/0            0.0.0.0/0            udp dpt:67
    0     0 ACCEPT     tcp  --  virbr0 *       0.0.0.0/0            0.0.0.0/0            tcp dpt:67
    0     0 ACCEPT     udp  --  tunnelbr0 *       0.0.0.0/0            0.0.0.0/0            udp dpt:53
    0     0 ACCEPT     tcp  --  tunnelbr0 *       0.0.0.0/0            0.0.0.0/0            tcp dpt:53
    0     0 ACCEPT     udp  --  tunnelbr0 *       0.0.0.0/0            0.0.0.0/0            udp dpt:67
    0     0 ACCEPT     tcp  --  tunnelbr0 *       0.0.0.0/0            0.0.0.0/0            tcp dpt:67
    0     0 ACCEPT     udp  --  mgmtbr0 *       0.0.0.0/0            0.0.0.0/0            udp dpt:53
    0     0 ACCEPT     tcp  --  mgmtbr0 *       0.0.0.0/0            0.0.0.0/0            tcp dpt:53
    0     0 ACCEPT     udp  --  mgmtbr0 *       0.0.0.0/0            0.0.0.0/0            udp dpt:67
    0     0 ACCEPT     tcp  --  mgmtbr0 *       0.0.0.0/0            0.0.0.0/0            tcp dpt:67
  193 17300 ACCEPT     all  --  br0    *       192.168.10.0/24      0.0.0.0/0           
    0     0 ACCEPT     all  --  br0    *       192.168.11.0/24      0.0.0.0/0           

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 ACCEPT     all  --  *      virbr0  0.0.0.0/0            192.168.122.0/24     ctstate RELATED,ESTABLISHED
    0     0 ACCEPT     all  --  virbr0 *       192.168.122.0/24     0.0.0.0/0           
    0     0 ACCEPT     all  --  virbr0 virbr0  0.0.0.0/0            0.0.0.0/0           
    0     0 REJECT     all  --  *      virbr0  0.0.0.0/0            0.0.0.0/0            reject-with icmp-port-unreachable
    0     0 REJECT     all  --  virbr0 *       0.0.0.0/0            0.0.0.0/0            reject-with icmp-port-unreachable
    0     0 ACCEPT     all  --  tunnelbr0 tunnelbr0  0.0.0.0/0            0.0.0.0/0           
    0     0 REJECT     all  --  *      tunnelbr0  0.0.0.0/0            0.0.0.0/0            reject-with icmp-port-unreachable
    0     0 REJECT     all  --  tunnelbr0 *       0.0.0.0/0            0.0.0.0/0            reject-with icmp-port-unreachable
    0     0 ACCEPT     all  --  mgmtbr0 mgmtbr0  0.0.0.0/0            0.0.0.0/0           
    0     0 REJECT     all  --  *      mgmtbr0  0.0.0.0/0            0.0.0.0/0            reject-with icmp-port-unreachable
    0     0 REJECT     all  --  mgmtbr0 *       0.0.0.0/0            0.0.0.0/0            reject-with icmp-port-unreachable

Chain OUTPUT (policy ACCEPT 132 packets, 17456 bytes)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 ACCEPT     udp  --  *      virbr0  0.0.0.0/0            0.0.0.0/0            udp dpt:68
    0     0 ACCEPT     udp  --  *      tunnelbr0  0.0.0.0/0            0.0.0.0/0            udp dpt:68
    0     0 ACCEPT     udp  --  *      mgmtbr0  0.0.0.0/0            0.0.0.0/0            udp dpt:68

Chain LOG_AND_DROP (0 references)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 LOG        all  --  *      *       0.0.0.0/0            0.0.0.0/0            LOG flags 0 level 7 prefix "iptables deny: "
    0     0 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0 

Output of iptables -L -n -v after running /etc/init.d/iptables-persistent start (expected result)

# iptables -L -n -v
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
   13   920 ACCEPT     all  --  br0    *       192.168.10.0/24      0.0.0.0/0           
    0     0 ACCEPT     all  --  br0    *       192.168.11.0/24      0.0.0.0/0           

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 8 packets, 1104 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain LOG_AND_DROP (0 references)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 LOG        all  --  *      *       0.0.0.0/0            0.0.0.0/0            LOG flags 0 level 7 prefix "iptables deny: "
    0     0 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0           
4
  • 1
    Please try your iptables listing again, and this time add the -v option. It is impossible to understand the firewall without it. Aug 16, 2014 at 17:32
  • I've not included that because the contents of the rules isn't what's concerning me - I'm trying to understand where they are being loaded from and where to edit them. -v doesn't provide any additional information about that. Aug 16, 2014 at 20:12
  • 1
    I didn't ask you to do that because I was bored. You really need to do this, because it does provide additional information. Aug 17, 2014 at 2:21
  • I've updated the iptables information with -v included. Aug 17, 2014 at 8:00

3 Answers 3

2

All of the "extra" rules you are seeing were added by the libvirt daemon to support (and secure) virtual networking for your virtual machine guests. You generally do not need to worry about these rules (and should not try to persist them, as then they would be duplicated at next boot).

It's also clear that all of your persistent firewall rules were added to the firewall.

It was between difficult and impossible to discern either of these facts without that critical -v switch for the `iptables command.

1
  • I'd still like to worry about where the libvirt rules are coming from. Given that I removed all of the nwfilter rules, where / how are these being set ? Aug 17, 2014 at 14:25
1

I know this question is very old, but since your question where these rules come from and how to customize them, is not fully answered yet, I will try to do so...

As Michael Hampton already told, these rules come from libvirt. Here are some quotes form the libvirt documentation:

Libvirt will optionally also provide DHCP services to the virtual network using DNSMASQ. In all cases, we need to allow DNS/DHCP queries to the host OS. Since we can't predict whether the host firewall setup is already allowing this, we insert 4 rules into the head of the INPUT chain

The next rules depend on the type of connectivity allowed, and go in the main FORWARD chain

The rules are controlled by "forward mode" in the configuration of each network. You can not modify these rules, since they are not in a configuration file or a script, but in the sourcecode. These iptables rules are not to be confused with the network-filters you mentioned (virsh nwfilter-list), since network-filters are applied to virtual machines. For more details see Network Filters.

In 2016 the "open"-network "forward mode" was added. When specified for a network, libvirt does not generate any iptables rules for the network. See bug 846810.

So edit your network (virsh net-edit) to <forward mode='open'/>.

open is like route, but there will be no firewall rules added to either enable or prevent any of this traffic. See Network XML format for more details.

0

Did you check in /etc/network/interfaces for "pre-up" directive, which may look something like:

pre-up iptables-restore < /etc/iptables.rules

Another possibility on Ubuntu/Debian is that scripts are located in /etc/network/if-pre-up.d/ directory, so you should list the contents of that dir:

# ls -al /etc/network/if-pre-up.d/

Another possibility is that NetworkManager loads the rules, and you can check that by searching for firewall/iptables in following directory:

/etc/NetworkManager/dispatcher.d/

Also, check all scripts in /etc/init and /etc/init.d for "iptables" and "iptables-restore".

1
  • There's no pre-up rule in my interfaces file for any interface. /etc/network/if-pre-up.d only contains the following which are all defaults: bridge ethtool wireless-tools wpasupplicant . Network Manager is disabled. I'm fairly sure this has something to do with the virbr0 interface which is defined by libvirt, not by anything in my networking. If I remove libvirt this issue does not appear. Aug 17, 2014 at 8:01

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.