A couple questions about LXC/D networking

I’m looking for help in clarifying a few things related to LXD networking. I tried to get more insight (also about “bridges”) from web articles, but with limited success.

  1. I noticed that LXD enables net.ipv4.ip_forward and adds the related iptables rules:

    -A FORWARD -o lxcbr0 -j ACCEPT
    -A FORWARD -i lxcbr0 -j ACCEPT

    Could you explain why this is needed? It it because the host serves as a sort of router/middleman for the containers and forwards packets to them?

  2. The ipv4.dhcp option in LXD seems to cause the following iptables rules to be added:

    -A INPUT -i lxcbr0 -p udp --dport 67 -j ACCEPT
    -A INPUT -i lxcbr0 -p udp --dport 53 -j ACCEPT
    -A INPUT -i lxcbr0 -p tcp --dport 53 -j ACCEPT
    -A OUTPUT -o lxcbr0 -p udp --sport 67 -j ACCEPT
    -A OUTPUT -o lxcbr0 -p udp --sport 53 -j ACCEPT
    -A OUTPUT -o lxcbr0 -p tcp --sport 53 -j ACCEPT

    These are just to allow incoming/outgoing DHCP and DNS negotiation, in case the firewall drops by default, correct?

  3. From what I understand, the following rule:

    -A POSTROUTING -o lxcbr0 -p udp -m udp --dport 68 -j CHECKSUM --checksum-fill

    …is required for older buggy DHCP clients, presumably in containers. Can I assume that this rule would not be needed at all for modern containers (like recent Ubuntu, Alpine)?

  4. The ipv4.firewall option serves as a master toggle for all of the above, correct?


  1. Yes, exactly, the containers are on an isolated bridge and internet access in/out of that needs routing by the host. Those rules aren’t needed on systems that don’t have a firewall running, but they are for those systems where the default policy for forwarding isn’t accept. As a result, we just always inject those rules for consistency.

  2. Correct

  3. That’s correct, yes. I don’t know the state of most distros and which one had the patch applied. Last I checked, this patch wasn’t part of the official ISC dhcp client release, so anything using dhclient and that wasn’t distro patched would hit the issue unless this rule is present.

  4. Yes, that key is used as a way to turn off our interactions with iptables/ip6tables for those that prefer to manage all that manually through separate firewalling scripts.

One slightly related, more general question. Could the iptables rule

iptables -t nat -A POSTROUTING -s ! -d -j MASQUERADE

…be replaced with a -j SNAT --to-source x.x.x.x solution if the LXD host is behind a router? I assumed the source IP would just have to be set to the ip of the host’s ethernet interface (e.g., but that doesn’t seem to work.

Maybe I’m misunderstanding what MASQUERADE actually does here, but reading online documentation didn’t bring me the insight I had hoped for.

masquerade is the same as nat overload in cisco speak, just hiding behind the egress interface IP.

I personally turn off nat and route to the container networks, run FRR with ospf on the container host and form adjacency with the core switch so it learns the routes of the various bridge networks via passive interfaces on the bridges.

natting works well if most of the connections are outbound only for the containers, but if you have a lot of inbound services then port forwarding with iptables becomes a bit of a chore. Also you could use haproxy inbound to the various containers so use as a tcp or http proxy.


Do you use the frr snap package? Can you give a simplified example of using frr with LXD to provide networking?

Hi Simos

I use the release deb from here: https://github.com/FRRouting/frr/releases

18.04 Bionic: https://github.com/FRRouting/frr/releases/download/frr-6.0.2/frr_6.0.2-0.ubuntu18.04.1_amd64.deb

to install:

apt update
apt install libc-ares2
dpkg -i frr_6.0.2-0.ubuntu18.04.1_amd64.deb

/// enable daemons

nano /etc/frr/daemons

/// uncomment what you want to enable

usually i start with zebra, ospf, bgpd (I think latest might use staticd instead of zebra)

systemctl restart frr

now to edit routing etc:

conf t
ip route
write mem

/// to address an interface

interface lxdbr0
  ip address

interface ens3
  ip address
write mem

usual cisco style config so edit your bgp, ospf, isis, bfd anything you want in the terminal vtysh

You can also run commands externally from bash with vtysh -c “ip route blah”