[SOLVED] Network is unavailable in an LXC container

x-yuri · 2022-10-19 10:43:44

Hi,

On the host:

23: lxcbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 00:16:3e:00:00:00 brd ff:ff:ff:ff:ff:ff
    inet 10.0.3.1/24 brd 10.0.3.255 scope global lxcbr0
       valid_lft forever preferred_lft forever
    inet6 fe80::216:3eff:fe00:0/64 scope link 
       valid_lft forever preferred_lft forever
27: vethckMLJq@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master lxcbr0 state UP group default qlen 1000
    link/ether fe:64:4c:3d:15:84 brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet6 fe80::fc64:4cff:fe3d:1584/64 scope link 
       valid_lft forever preferred_lft forever

In the container:

2: eth0@if27: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 00:16:3e:56:99:8a brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet 10.0.3.194/24 brd 10.0.3.255 scope global dynamic eth0
       valid_lft 3262sec preferred_lft 3262sec
    inet6 fe80::216:3eff:fe56:998a/64 scope link 
       valid_lft forever preferred_lft forever

10.0.3.1 is reachable from the container, but that's probably all:

$ lxc-attach c ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.

Any suggestions are welcome.

Last edited by x-yuri (2022-10-20 06:59:53)

x-yuri · 2022-10-20 06:57:08

Okay, it appears that the policy of the FORWARD chain in the filter table was set to DROP for some reason (UPD the docker's doing).

I investigated it a bit further and added some logging:

*mangle
:PREROUTING ACCEPT
:INPUT ACCEPT
:FORWARD ACCEPT
:OUTPUT ACCEPT
:POSTROUTING ACCEPT
-A PREROUTING -p icmp -j LOG --log-prefix "mangle: PREROUTING: "
-A INPUT -p icmp -j LOG --log-prefix "mangle: INPUT: "
-A FORWARD -p icmp -j LOG --log-prefix "mangle: FORWARD: "
-A OUTPUT -p icmp -j LOG --log-prefix "mangle: OUTPUT: "
-A POSTROUTING -p icmp -j LOG --log-prefix "mangle: POSTROUTING: "
COMMIT

*security
:INPUT ACCEPT
:FORWARD ACCEPT
:OUTPUT ACCEPT
-A INPUT -p icmp -j LOG --log-prefix "security: INPUT: "
-A FORWARD -p icmp -j LOG --log-prefix "security: FORWARD: "
-A OUTPUT -p icmp -j LOG --log-prefix "security: OUTPUT: "
COMMIT

*raw
:PREROUTING ACCEPT
:OUTPUT ACCEPT
-A PREROUTING -p icmp -j LOG --log-prefix "raw: PREROUTING: "
-A OUTPUT -p icmp -j LOG --log-prefix "raw: OUTPUT: "
COMMIT

*filter
:INPUT ACCEPT
:FORWARD ACCEPT
:OUTPUT ACCEPT
-A INPUT -p icmp -j LOG --log-prefix "filter: INPUT: "
-A FORWARD -p icmp -j LOG --log-prefix "filter: FORWARD: "
-A OUTPUT -p icmp -j LOG --log-prefix "filter: OUTPUT: "
COMMIT

*nat
:PREROUTING ACCEPT
:INPUT ACCEPT
:OUTPUT ACCEPT
:POSTROUTING ACCEPT
-A PREROUTING -p icmp -j LOG --log-prefix "nat: PREROUTING: "
-A INPUT -p icmp -j LOG --log-prefix "nat: INPUT: "
-A OUTPUT -p icmp -j LOG --log-prefix "nat: OUTPUT: "
-A POSTROUTING -p icmp -j LOG --log-prefix "nat: POSTROUTING: "
COMMIT

On a side-note it appears one can reset iptables by iptables-apply'ing the following file:

*mangle
COMMIT
*security
COMMIT
*raw
COMMIT
*filter
COMMIT
*nat
COMMIT

With that what I could see in the journal when I pinged my physical router (192.168.88.1) from the container is this:

raw:      PREROUTING:  IN=lxcbr0 OUT=     SRC=10.0.3.221 DST=192.168.88.1
mangle:   PREROUTING:  IN=lxcbr0 OUT=     SRC=10.0.3.221 DST=192.168.88.1
nat:      PREROUTING:  IN=lxcbr0 OUT=     SRC=10.0.3.221 DST=192.168.88.1
mangle:   FORWARD:     IN=lxcbr0 OUT=wlo1 SRC=10.0.3.221 DST=192.168.88.1
filter:   FORWARD:     IN=lxcbr0 OUT=wlo1 SRC=10.0.3.221 DST=192.168.88.1
security: FORWARD:     IN=lxcbr0 OUT=wlo1 SRC=10.0.3.221 DST=192.168.88.1
mangle:   POSTROUTING: IN=lxcbr0 OUT=wlo1 SRC=10.0.3.221 DST=192.168.88.1
nat:      POSTROUTING: IN=lxcbr0 OUT=wlo1 SRC=10.0.3.221 DST=192.168.88.1

raw:      PREROUTING:  IN=wlo1 OUT=                        DST=192.168.88.250
mangle:   PREROUTING:  IN=wlo1 OUT=       SRC=192.168.88.1 DST=192.168.88.250
mangle:   FORWARD:     IN=wlo1 OUT=lxcbr0 SRC=192.168.88.1 DST=10.0.3.221
filter:   FORWARD:     IN=wlo1 OUT=lxcbr0 SRC=192.168.88.1 DST=10.0.3.221
security: FORWARD:     IN=wlo1 OUT=lxcbr0 SRC=192.168.88.1 DST=10.0.3.221
mangle:   POSTROUTING: IN=wlo1 OUT=lxcbr0 SRC=192.168.88.1 DST=10.0.3.221

10.0.3.221 is apparently the IP of the container. For some reason the response didn't pass through the nat table.

Anyways, I'm trying to figure out how it all works. Apparently I have 2 subnets here. 192.168.88.0/24 with the physical router (192.168.88.1) and me (192.168.88.250). And 10.0.3.0/24 with the bridge (10.0.3.1) and the container (10.0.3.221).

Also the routing tables on the host and in the container differ. Which suggests that there are 2 routers. One routing table is stored... on the physical router?.. And the other... in the container? And the second router is the kernel? Or maybe there are 3 routers (one physical and 2 software ones)?

Additionally, iptables-save produces different results in the container and on the host. That's probably can be explained by the fact that the host and the container are in different network namespaces.

I tend to think that there are 3 routers: one physical and 2 software ones. The software ones are basically some kernel component running in 2 network namespaces. As such the routing tables I see are of the software routers.

Another tricky thing is that the bridge has an IP address. I guess generally physical bridges don't have IP addresses. Probably a peculiarity of a software bridge.

If anyone could confirm, deny or comment on this (put it into proper words?), that would be nice.

Last edited by x-yuri (2022-10-20 09:21:57)

Arch Linux

#1 2022-10-19 10:43:44

[SOLVED] Network is unavailable in an LXC container

#2 2022-10-20 06:57:08

Re: [SOLVED] Network is unavailable in an LXC container

Board footer