Upgraded to Ubuntu 20.10, now no ipv4

LXD
1

Hi! I upgraded ubuntu to 20.10 because I love to live on the edge. Unfortunately it seems that my containers now have a networking issue where eth0 only gets an ipv6 address.

My bridge looks like the following.

lxc network show lxdbr0                                                                 
config:
  ipv4.address: 10.93.148.1/24
  ipv4.nat: "true"
  ipv6.address: none
  ipv6.nat: "false"
  raw.dnsmasq: |
    auth-zone=lxd
    dns-loop-detect
description: ""
name: lxdbr0
type: bridge
used_by:
- /1.0/instances/audit
- /1.0/instances/cloud
- /1.0/instances/kerberos
- /1.0/profiles/default
managed: true
status: Created
locations:
- none
2

The few usual suspects would be:

  • docker being installed on the host
  • dnsmasq unable to start (check with ps aux | grep dnsmasq)
  • firewalld or other firewall blocking traffic (iptables -L -n -v)
3

Thanks @stgraber,

It looks like docker was installed but that was not the issue, dnsmasq was running too.

However I was using ufw for firewall rules and disabling the ufw rules worked. Since these same rules worked before I wonder what changed in Ubuntu 20.10. I’ll keep investigating, thank you much!

1 Like
4

I have this problem as well (even after stopping the Docker daemon). I notice that the legacy iptables is always enabled after LXD is started, is this proper behavior?

5

LXD tries to identify the ‘correct’ firewall driver to use, however it can still lead to having mixed iptables/nftables setup on systems where there is already mixed usage.

First, lets see what LXD has chosen to use:

Please show output of:

lxc info | grep 'firewall:'

Then please show output of:

sudo iptables-save
sudo nft list ruleset

1 Like
6 
  firewall: nftables

# Generated by iptables-save v1.8.5 on Thu Feb 18 17:26:48 2021
*nat
:PREROUTING ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
COMMIT
# Completed on Thu Feb 18 17:26:48 2021
# Generated by iptables-save v1.8.5 on Thu Feb 18 17:26:48 2021
*filter
:INPUT ACCEPT [0:0]
:FORWARD DROP [8633:526461]
:OUTPUT ACCEPT [0:0]
COMMIT
# Completed on Thu Feb 18 17:26:48 2021
# Generated by iptables-save v1.8.5 on Thu Feb 18 17:26:48 2021
*mangle
:PREROUTING ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
COMMIT
# Completed on Thu Feb 18 17:26:48 2021
# Warning: iptables-legacy tables present, use iptables-legacy-save to see them

table ip nat {
        chain PREROUTING {
                type nat hook prerouting priority dstnat; policy accept;
        }

        chain INPUT {
                type nat hook input priority 100; policy accept;
        }

        chain POSTROUTING {
                type nat hook postrouting priority srcnat; policy accept;
        }

        chain OUTPUT {
                type nat hook output priority -100; policy accept;
        }
}
table ip filter {
        chain INPUT {
                type filter hook input priority filter; policy accept;
        }

        chain FORWARD {
                type filter hook forward priority filter; policy drop;
        }

        chain OUTPUT {
                type filter hook output priority filter; policy accept;
        }
}
table ip lxd {
        chain in.lxdbr0 {
                type filter hook input priority filter; policy accept;
                iifname "lxdbr0" tcp dport 53 accept
                iifname "lxdbr0" udp dport 53 accept
                iifname "lxdbr0" udp dport 67 accept
        }

        chain out.lxdbr0 {
                type filter hook output priority filter; policy accept;
                oifname "lxdbr0" tcp sport 53 accept
                oifname "lxdbr0" udp sport 53 accept
                oifname "lxdbr0" udp sport 67 accept
        }

        chain fwd.lxdbr0 {
                type filter hook forward priority filter; policy accept;
                oifname "lxdbr0" accept
                iifname "lxdbr0" accept
        }

        chain pstrt.lxdbr0 {
                type nat hook postrouting priority srcnat; policy accept;
                @nh,96,24 714690 @nh,128,24 != 714690 masquerade
        }
}
table ip6 lxd {
        chain in.lxdbr0 {
                type filter hook input priority filter; policy accept;
                iifname "lxdbr0" tcp dport 53 accept
                iifname "lxdbr0" udp dport 53 accept
                iifname "lxdbr0" udp dport 547 accept
        }

        chain out.lxdbr0 {
                type filter hook output priority filter; policy accept;
                oifname "lxdbr0" tcp sport 53 accept
                oifname "lxdbr0" udp sport 53 accept
                oifname "lxdbr0" udp sport 547 accept
        }

        chain fwd.lxdbr0 {
                type filter hook forward priority filter; policy accept;
                oifname "lxdbr0" accept
                iifname "lxdbr0" accept
        }

        chain pstrt.lxdbr0 {
                type nat hook postrouting priority srcnat; policy accept;
                @nh,64,64 18249383650777211165 @nh,192,64 != 18249383650777211165 masquerade
        }
}
table ip mangle {
        chain PREROUTING {
                type filter hook prerouting priority mangle; policy accept;
        }

        chain INPUT {
                type filter hook input priority mangle; policy accept;
        }

        chain FORWARD {
                type filter hook forward priority mangle; policy accept;
        }

        chain OUTPUT {
                type route hook output priority mangle; policy accept;
        }

        chain POSTROUTING {
                type filter hook postrouting priority mangle; policy accept;
        }
}

Also, the output of iptables-legacy-save:

# Generated by iptables-save v1.8.5 on Thu Feb 18 17:30:54 2021
*raw
:PREROUTING ACCEPT [398488:174297561]
:OUTPUT ACCEPT [326806:43507239]
COMMIT
# Completed on Thu Feb 18 17:30:54 2021
# Generated by iptables-save v1.8.5 on Thu Feb 18 17:30:54 2021
*mangle
:PREROUTING ACCEPT [398488:174297561]
:INPUT ACCEPT [388538:172761712]
:FORWARD ACCEPT [32:2064]
:OUTPUT ACCEPT [326806:43507239]
:POSTROUTING ACCEPT [332306:46992998]
COMMIT
# Completed on Thu Feb 18 17:30:54 2021
# Generated by iptables-save v1.8.5 on Thu Feb 18 17:30:54 2021
*nat
:PREROUTING ACCEPT [13450:1347394]
:INPUT ACCEPT [5130:865086]
:OUTPUT ACCEPT [32021:3992257]
:POSTROUTING ACCEPT [31933:3979277]
COMMIT
# Completed on Thu Feb 18 17:30:54 2021
# Generated by iptables-save v1.8.5 on Thu Feb 18 17:30:54 2021
*filter
:INPUT ACCEPT [388538:172761712]
:FORWARD ACCEPT [32:2064]
:OUTPUT ACCEPT [326806:43507239]
COMMIT
# Completed on Thu Feb 18 17:30:54 2021
7

OK good, so you have a ‘pure’ nftables setup.

One thing that I can see is likely to cause you problems is this:

table ip filter {
...
        chain FORWARD {
                type filter hook forward priority filter; policy drop;
        }

...
}

The policy drop bit is going to cause all routed traffic (i.e traffic to/from containers going to your external NIC) to be dropped. This is because nftables has a somewhat counter intuitive behaviour (compared to iptables) where when a rule in a chain (in this case fwd.lxdbr0) accepts traffic, this doesn’t necessarily mean it will actually get accepted, as nftables then considers all other chains and if one of them has a drop rule (or default policy) then the packet is dropped even though it was supposed to have been accepted earlier.

See Configuring chains - nftables wiki

NOTE : If a packet is accepted and there is another chain, bearing the same hook type and with a later priority, then the packet will subsequently traverse this other chain. Hence, an accept verdict - be it by way of a rule or the default chain policy - isn’t necessarily final. However, the same is not true of packets that are subjected to a drop verdict. Instead, drops take immediate effect, with no further rules or chains being evaluated.

We have discussed this before, see Lxd bridge doesn't work with IPv4 and UFW with nftables - #13 by tomp

So you’re going to want to change that to an accept.

However before that I am not seeing any reason why your containers are not getting IPv4 addresses from dnsmasq listening on lxdbr0 via DHCP.

Can you show output of:

sudo ss -ulpn
1 Like
8

I would like to clarify that the container did obtain an IPv4 address, just have no internet connectivity:

brlin@brlin-musicha-mz-530:~$ lxc list
+------+---------+----------------------+----------------------------------------------+-----------+-----------+
| NAME |  STATE  |         IPV4         |                     IPV6                     |   TYPE    | SNAPSHOTS |
+------+---------+----------------------+----------------------------------------------+-----------+-----------+
| u1   | RUNNING | 10.231.194.66 (eth0) | fd42:d5bd:b265:a11d:216:3eff:fe5a:fa0 (eth0) | CONTAINER | 0         |
+------+---------+----------------------+----------------------------------------------+-----------+-----------+
brlin@brlin-musicha-mz-530:~$ lxc shell u1
root@u1:~# ping 1.1.1.1
PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data.

(stuck at here)
^C
--- 1.1.1.1 ping statistics ---
70 packets transmitted, 0 received, 100% packet loss, time 70652ms
9

Oh I see, the subject line of the thread “no IPv4” confused me, but that was the original poster’s subject and not yours :slight_smile:

In that case, the default drop rule on the FORWARD chain is the issue.

1 Like
10

Thanks for identifying the problem, I have regain internet access now.

1 Like