How to re-initialize iptables rules?

(Matt) #1

When LXD starts, some rules are added to iptables to make the containers able to access the internet, and to communicate with the host.

In my case, I have many other custom rules, and the two play along without problems. However, at times I have the need to reset the firewall by clearing all the rules. This, of course, deletes the rules inserted by LXD as well.

Is there any way to have LXD reinsert those rules into the (now empty) firewall?

PS In case it matters: I am using LXC installed via snap as per these instructions.

(David Negreira) #2

I would say that you can do it with an LXD restart

(Matt) #3

And how to restart LXD?

In my case (snap package) service lxd restart gives error.

(David Negreira) #4

Try with sudo snap restart lxd

(Matt) #5

Thank you very much for your suggestion. This indeed works, and rules are regenerated properly.

However, according to my tests it “resets” the containers, too: i.e. if I login into a container with lxc exec mycontainer bash the connection is dropped.

Any suggestion for a “softer” method? Somewhere in the Internet I had found hints about a shell script, part of lxd, which could be called for exactly this purpose. The script was not to be found on my system, maybe because of different versions, or different packaging system (apt vs snap).

(David Negreira) #6

The reset is only due to the fact that you exec a command through LXD and restart it, the container itself keeps running without any impact to the container.

(Matt) #7

Unfortunately, it seems that this is not the case. Here is my test.

First, I start a dummy background process, and leave the container shell:

matteo@matteo-desktop:~$ lxc exec test bash
root@test:~# nohup sleep 1d &> /dev/null &
[1] 17181
root@test:~# ps aux | grep sleep
root     17181  0.0  0.0   7712   632 ?        S    22:44   0:00 sleep 1d
root     26985  0.0  0.0  14620   788 ?        S+   22:45   0:00 grep --color=auto sleep
root@test:~# exit

Then I restart lxd:

matteo@matteo-desktop:~$ sudo snap restart lxd

Then quickly, try to reaccess the container:

matteo@matteo-desktop:~$ lxc exec test bash
Error: Container is not running.

Give it time to come back up, and try again. The process is gone.

matteo@matteo-desktop:~$ lxc exec test bash
root@test:~# ps aux | grep sleep
root      1467  0.0  0.0  14620   816 ?        S+   22:45   0:00 grep --color=auto sleep

So it seems to me that the container has been reset. Any thoughts?

(David Negreira) #8

Yes, you are correct, I can replicate the same.
It seems that when you do a restart via snap the containers are indeed stopped when LXD is restarted, this does not happen with the deb package.
@stgraber any ideas?

(Stéphane Graber) #9

Use systemctl reload snap.lxd.daemon as snap restart lxd or systemctl restart snap.lxd.daemon will cause a “clean” shutdown of the LXD daemon, shutting down all the containers in the process.

When the snap package updates (refresh), a reload is performed, specifically so that containers don’t get respawned. Unfortunately we can’t make snap restart lxd do that as what it does is call systemctl restart lxd which in turn is the same as systemctl stop and systemctl start and we do need systemctl stop to shutdown all containers as otherwise we’d get data corruption when you shutdown or reboot the server.

(Matt) #10

Indeed: systemctl reload snap.lxd.daemon seems to work perfectly in this case. I assume systemctl reload lxd will do the same in case LXD was installed via apt package.

Thank you all for your support!


I am facing a smiliar situation where the firewall is reloading every 24 hours for maintenance and in the process flushing the entire iptable, after wich the LXC container(s) loosing connectivity.

The box is running LXC straight off without snapd and tried systemctl reload lxc with output

Failed to reload lxc.service: Job type reload is not applicable for unit lxc.service.

another firewall restart scenario is when the firewall userland app gets an update.

Since the firewall is supporing scripts it is perhaps best practice to restart lxc.service and lxc-net.service, however that leads to a bief interruption of service provided by a container. Reloading instead would perhaps be less intrusive.

(Matt) #12

Did you try systemctl reload lxd (i.e with lxd as opposed to lxc)?


Not using LXD, I am afraid