LXC Container on same network as host with internet access

Hello and greetings!

First of all let me tell what network configuration I am trying to achieve:

  1. LXC container should be exposed to my local network
  2. LXC container should have internet access

Here’s what I have been able to achieve so far:

I have referred to Converting eth0 to br0 and getting all your LXC or LXD onto your LAN | Ubuntu to achieve requirement #1 in the above configuration. However, LXC does not have internet connection.

Some other observations:

  • I am able to ping to & from all devices on the network except the LXC container.
  • I am able to ping to & from LXC container to it’s host: the Ubuntu VM.

I referred to some topics on this forum which are relevant to my problem, but no avail. Any ideas as to how to enable internet access inside container?


On Host (Ubuntu VM)

ajinkya@metaverse:~$ lsb_release -a
No LSB modules are available.
Distributor ID:	Ubuntu
Description:	Ubuntu 20.04.2 LTS
Release:	20.04
Codename:	focal
ajinkya@metaverse:~$ lxc-ls --version
4.0.6
ajinkya@metaverse:~$ uname -a
Linux metaverse 5.11.0-25-generic #27~20.04.1-Ubuntu SMP Tue Jul 13 17:41:23 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
------------------------------------------------------------------------------------
ajinkya@metaverse:~$ ip a show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: enp0s3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel master br0 state UP group default qlen 1000
    link/ether 08:00:27:db:a6:da brd ff:ff:ff:ff:ff:ff
3: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 08:00:27:db:a6:da brd ff:ff:ff:ff:ff:ff
    inet 192.168.0.161/24 brd 192.168.0.255 scope global dynamic br0
       valid_lft 85283sec preferred_lft 85283sec
    inet6 fd01::124:c625:211:6384/64 scope global temporary dynamic 
       valid_lft 251sec preferred_lft 251sec
    inet6 fd01::a00:27ff:fedb:a6da/64 scope global dynamic mngtmpaddr 
       valid_lft 251sec preferred_lft 251sec
    inet6 fe80::a00:27ff:fedb:a6da/64 scope link 
       valid_lft forever preferred_lft forever
4: veth1000_JY5u@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br0 state UP group default qlen 1000
    link/ether fe:03:d9:b4:05:29 brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet6 fe80::fc03:d9ff:feb4:529/64 scope link 
       valid_lft forever preferred_lft forever

------------------------------------------------------------------------------------
ajinkya@metaverse:~$ brctl show
bridge name	bridge id		    STP enabled	     interfaces
br0		    8000.080027dba6da	no		         enp0s3
							                     veth1000_JY5u
------------------------------------------------------------------------------------
ajinkya@metaverse:~$ cat /etc/default/lxc-net
# This file is auto-generated by lxc.postinst if it does not
# exist.  Customizations will not be overridden.
# Leave USE_LXC_BRIDGE as "true" if you want to use lxcbr0 for your
# containers.  Set to "false" if you'll use virbr0 or another existing
# bridge, or mavlan to your host's NIC.
USE_LXC_BRIDGE="false"

# If you change the LXC_BRIDGE to something other than lxcbr0, then
# you will also need to update your /etc/lxc/default.conf as well as the
# configuration (/var/lib/lxc/<container>/config) for any containers
# already created using the default config to reflect the new bridge
# name.
# If you have the dnsmasq daemon installed, you'll also have to update
# /etc/dnsmasq.d/lxc and restart the system wide dnsmasq daemon.
LXC_BRIDGE="lxcbr0"
LXC_ADDR="10.0.3.1"
LXC_NETMASK="255.255.255.0"
LXC_NETWORK="10.0.3.0/24"
LXC_DHCP_RANGE="10.0.3.2,10.0.3.254"
LXC_DHCP_MAX="253"
# Uncomment the next line if you'd like to use a conf-file for the lxcbr0
# dnsmasq.  For instance, you can use 'dhcp-host=mail1,10.0.3.100' to have
# container 'mail1' always get ip address 10.0.3.100.
#LXC_DHCP_CONFILE=/etc/lxc/dnsmasq.conf

# Uncomment the next line if you want lxcbr0's dnsmasq to resolve the .lxc
# domain.  You can then add "server=/lxc/10.0.3.1' (or your actual $LXC_ADDR)
# to your system dnsmasq configuration file (normally /etc/dnsmasq.conf,
# or /etc/NetworkManager/dnsmasq.d/lxc.conf on systems that use NetworkManager).
# Once these changes are made, restart the lxc-net and network-manager services.
# 'container1.lxc' will then resolve on your host.
#LXC_DOMAIN="lxc"
------------------------------------------------------------------------------------
ajinkya@metaverse:~$ cat /etc/lxc/default.conf 
lxc.net.0.type = veth
lxc.net.0.link = br0
lxc.net.0.flags = up
lxc.net.0.hwaddr = 00:16:3e:xx:xx:xx
------------------------------------------------------------------------------------
ajinkya@metaverse:~$ cat .config/lxc/default.conf
lxc.include = /etc/lxc/default.conf
lxc.idmap = u 0 100000 65536
lxc.idmap = g 0 100000 65536
------------------------------------------------------------------------------------
ajinkya@metaverse:~$ lxc-ls --fancy
NAME STATE   AUTOSTART GROUPS IPV4          IPV6                     UNPRIVILEGED 
con1 RUNNING 0         -      192.168.0.185 fd01::216:3eff:fe67:d14e true 
------------------------------------------------------------------------------------

On container

root@con1:/# lsb_release -a
No LSB modules are available.
Distributor ID:	Ubuntu
Description:	Ubuntu 16.04.7 LTS
Release:	16.04
Codename:	xenial
root@con1:/# uname -a
Linux con1 5.11.0-25-generic #27~20.04.1-Ubuntu SMP Tue Jul 13 17:41:23 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
------------------------------------------------------------------------------------
root@con1:/# ip a show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0@if4: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 00:16:3e:67:d1:4e brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet 192.168.0.185/24 brd 192.168.0.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fd01::216:3eff:fe67:d14e/64 scope global mngtmpaddr dynamic 
       valid_lft 272sec preferred_lft 272sec
    inet6 fe80::216:3eff:fe67:d14e/64 scope link 
       valid_lft forever preferred_lft forever
------------------------------------------------------------------------------------
root@con1:/# ping google.com
ping: unknown host google.com
------------------------------------------------------------------------------------
root@con1:/# ping 192.168.0.161
PING 192.168.0.161 (192.168.0.161) 56(84) bytes of data.
64 bytes from 192.168.0.161: icmp_seq=1 ttl=64 time=0.115 ms
64 bytes from 192.168.0.161: icmp_seq=2 ttl=64 time=0.133 ms
64 bytes from 192.168.0.161: icmp_seq=3 ttl=64 time=0.189 ms
64 bytes from 192.168.0.161: icmp_seq=4 ttl=64 time=0.127 ms
^C
--- 192.168.0.161 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3069ms
rtt min/avg/max/mdev = 0.115/0.141/0.189/0.028 ms
------------------------------------------------------------------------------------

Check that the connection between the VM and the host isn’t filtering MAC addresses, and it may well need to be in promiscuous mode.

Thank you for replying @tomp
I already had the VM use ‘Allow All’ promiscuous mode, so that doesn’t help. I am pretty much sure there isn’t any MAC filtering being done, can you please let me know how do I check for it?

In that case check the firewall on the VM and host, and use tcpdump to trace the packet from the container to the VM host to the external network and see where its being dropped.

Hey @tomp,
I don’t have tcpdump preinstalled inside the container and I can not install it via apt-get since internet is not accessible from inside the container.

Thanks for replying.

But you can still install it on the VM right and do the diagnostics there?

Sorry for the previous reply, I wasn’t aware of the tcpdump usage and I did some reading and ran the following diagnostic commands:

Device IP
Container 192.168.0.185
Ubuntu VM 192.168.0.161
Ubuntu Host 192.168.0.166
Windows‎‎‎‎ 192.168.0.117
Router 192.168.0.1
ajinkya@metaverse:~$ sudo tcpdump src 192.168.0.185
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on br0, link-type EN10MB (Ethernet), capture size 262144 bytes

1. Ping Ubuntu VM from container:

root@con1:/# ping -c 4 192.168.0.161
PING 192.168.0.161 (192.168.0.161) 56(84) bytes of data.
64 bytes from 192.168.0.161: icmp_seq=1 ttl=64 time=0.136 ms
64 bytes from 192.168.0.161: icmp_seq=2 ttl=64 time=0.137 ms
64 bytes from 192.168.0.161: icmp_seq=3 ttl=64 time=0.140 ms
64 bytes from 192.168.0.161: icmp_seq=4 ttl=64 time=0.135 ms

--- 192.168.0.161 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3079ms
rtt min/avg/max/mdev = 0.135/0.137/0.140/0.002 ms
Corresponding tcpdump:
15:45:06.789224 IP 192.168.0.185 > metaverse: ICMP echo request, id 499, seq 1, length 64
15:45:07.824442 IP 192.168.0.185 > metaverse: ICMP echo request, id 499, seq 2, length 64
15:45:08.844715 IP 192.168.0.185 > metaverse: ICMP echo request, id 499, seq 3, length 64
15:45:09.868664 IP 192.168.0.185 > metaverse: ICMP echo request, id 499, seq 4, length 64
15:45:12.044572 ARP, Reply 192.168.0.185 is-at 00:16:3e:67:d1:4e (oui Unknown), length 28

2. Ping Ubuntu host from container:

root@con1:/# ping -c 4 192.168.0.166
PING 192.168.0.166 (192.168.0.166) 56(84) bytes of data.
64 bytes from 192.168.0.166: icmp_seq=1 ttl=64 time=0.480 ms
64 bytes from 192.168.0.166: icmp_seq=2 ttl=64 time=0.569 ms
64 bytes from 192.168.0.166: icmp_seq=3 ttl=64 time=0.214 ms
64 bytes from 192.168.0.166: icmp_seq=4 ttl=64 time=0.330 ms

--- 192.168.0.166 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3022ms
rtt min/avg/max/mdev = 0.214/0.398/0.569/0.137 ms
Corresponding tcpdump:
15:47:18.000937 IP 192.168.0.185 > ubuntu: ICMP echo request, id 503, seq 1, length 64
15:47:19.002322 IP 192.168.0.185 > ubuntu: ICMP echo request, id 503, seq 2, length 64
15:47:20.003253 IP 192.168.0.185 > ubuntu: ICMP echo request, id 503, seq 3, length 64
15:47:21.023294 IP 192.168.0.185 > ubuntu: ICMP echo request, id 503, seq 4, length 64
15:47:23.056436 ARP, Reply 192.168.0.185 is-at 00:16:3e:67:d1:4e (oui Unknown), length 28

3. Ping Windows from container:

root@con1:/# ping -c 4 192.168.0.117
PING 192.168.0.117 (192.168.0.117) 56(84) bytes of data.
From 192.168.0.185 icmp_seq=1 Destination Host Unreachable
From 192.168.0.185 icmp_seq=2 Destination Host Unreachable
From 192.168.0.185 icmp_seq=3 Destination Host Unreachable
From 192.168.0.185 icmp_seq=4 Destination Host Unreachable

--- 192.168.0.117 ping statistics ---
4 packets transmitted, 0 received, +4 errors, 100% packet loss, time 3052ms
pipe 4
Corresponding tcpdump:
15:52:32.046894 ARP, Request who-has DESKTOP-51OS6J2 tell 192.168.0.185, length 28
15:52:33.050544 ARP, Request who-has DESKTOP-51OS6J2 tell 192.168.0.185, length 28
15:52:34.074708 ARP, Request who-has DESKTOP-51OS6J2 tell 192.168.0.185, length 28

4. Ping router from container:

root@con1:/# ping -c 4 192.168.0.1
PING 192.168.0.1 (192.168.0.1) 56(84) bytes of data.

--- 192.168.0.1 ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 3051ms
Corresponding tcpdump:
16:07:00.032587 IP 192.168.0.185 > dlinkrouter: ICMP echo request, id 510, seq 1, length 64
16:07:00.053363 ARP, Reply 192.168.0.185 is-at 00:16:3e:67:d1:4e (oui Unknown), length 28
16:07:01.040066 IP 192.168.0.185 > dlinkrouter: ICMP echo request, id 510, seq 2, length 64
16:07:02.064054 IP 192.168.0.185 > dlinkrouter: ICMP echo request, id 510, seq 3, length 64
16:07:03.084129 IP 192.168.0.185 > dlinkrouter: ICMP echo request, id 510, seq 4, length 64
16:07:05.132164 ARP, Request who-has dlinkrouter tell 192.168.0.185, length 28
16:07:06.156233 ARP, Request who-has dlinkrouter tell 192.168.0.185, length 28
16:07:07.183942 ARP, Request who-has dlinkrouter tell 192.168.0.185, length 28

5. Ping google.com from container:

root@con1:/# ping google.com
ping: unknown host google.com
Corresponding tcpdump:
15:54:16.158231 IP 192.168.0.185.57213 > dlinkrouter.domain: 18560+ A? google.com. (28)
15:54:16.213271 ARP, Reply 192.168.0.185 is-at 00:16:3e:67:d1:4e (oui Unknown), length 28
15:54:21.161966 IP 192.168.0.185.50985 > dns.google.domain: 18560+ A? google.com. (28)
15:54:21.256921 ARP, Request who-has dlinkrouter tell 192.168.0.185, length 28
15:54:22.280819 ARP, Request who-has dlinkrouter tell 192.168.0.185, length 28
15:54:23.304779 ARP, Request who-has dlinkrouter tell 192.168.0.185, length 28
15:54:24.165754 IP 192.168.0.185.58761 > dns.google.domain: 18560+ A? google.com. (28)
15:54:30.169073 ARP, Request who-has dlinkrouter tell 192.168.0.185, length 28
15:54:30.369846 IP 192.168.0.185.57213 > dlinkrouter.domain: 18560+ A? google.com. (28)
15:54:35.173435 IP 192.168.0.185.50985 > dns.google.domain: 18560+ A? google.com. (28)
15:54:35.593548 ARP, Request who-has dlinkrouter tell 192.168.0.185, length 28
15:54:36.616926 ARP, Request who-has dlinkrouter tell 192.168.0.185, length 28
15:54:37.640893 ARP, Request who-has dlinkrouter tell 192.168.0.185, length 28
15:54:38.176410 IP 192.168.0.185.58761 > dns.google.domain: 18560+ A? google.com. (28)
15:54:44.182361 ARP, Request who-has dlinkrouter tell 192.168.0.185, length 28
15:54:45.192864 ARP, Request who-has dlinkrouter tell 192.168.0.185, length 28
15:54:45.933473 IP 192.168.0.185.56999 > dlinkrouter.domain: 12607+ A? google.com. (28)
15:54:49.661170 IP 192.168.0.185.47018 > dns.google.domain: 12607+ A? google.com. (28)
15:54:51.170325 ARP, Request who-has dlinkrouter tell 192.168.0.185, length 28
15:54:52.194001 ARP, Request who-has dlinkrouter tell 192.168.0.185, length 28
15:54:52.663172 IP 192.168.0.185.50867 > dns.google.domain: 12607+ A? google.com. (28)
15:54:53.218040 ARP, Request who-has dlinkrouter tell 192.168.0.185, length 28
15:54:58.668727 ARP, Request who-has dlinkrouter tell 192.168.0.185, length 28
15:54:59.678099 IP 192.168.0.185.56999 > dlinkrouter.domain: 12607+ A? google.com. (28)
15:55:03.673237 IP 192.168.0.185.47018 > dns.google.domain: 12607+ A? google.com. (28)
15:55:04.738183 ARP, Request who-has dlinkrouter tell 192.168.0.185, length 28
15:55:05.762124 ARP, Request who-has dlinkrouter tell 192.168.0.185, length 28
15:55:06.674162 IP 192.168.0.185.50867 > dns.google.domain: 12607+ A? google.com. (28)
15:55:06.785961 ARP, Request who-has dlinkrouter tell 192.168.0.185, length 28

Please let me know if you have any observations.

Do you see these ARP requests from the container making it out of the external interface in your VM?

I am not sure how do I track those ARP requests, here’s what I could come up with:

On container

root@con1:/# ping -c 4 192.168.0.1
PING 192.168.0.1 (192.168.0.1) 56(84) bytes of data.

--- 192.168.0.1 ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 3504ms

Monitoring on Ubuntu VM

ajinkya@metaverse:~$ sudo tcpdump src 192.168.0.185
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on br0, link-type EN10MB (Ethernet), capture size 262144 bytes
17:29:53.133192 IP 192.168.0.185 > dlinkrouter: ICMP echo request, id 517, seq 1, length 64
17:29:53.168106 ARP, Reply 192.168.0.185 is-at 00:16:3e:67:d1:4e (oui Unknown), length 28
17:29:54.593523 IP 192.168.0.185 > dlinkrouter: ICMP echo request, id 517, seq 2, length 64
17:29:55.617412 IP 192.168.0.185 > dlinkrouter: ICMP echo request, id 517, seq 3, length 64
17:29:56.637409 IP 192.168.0.185 > dlinkrouter: ICMP echo request, id 517, seq 4, length 64
17:29:58.621292 ARP, Request who-has dlinkrouter tell 192.168.0.185, length 28
17:29:59.645308 ARP, Request who-has dlinkrouter tell 192.168.0.185, length 28
17:30:00.669398 ARP, Request who-has dlinkrouter tell 192.168.0.185, length 28

Monitoring on Ubuntu Host

ajinkya@ubuntu:~$ sudo tcpdump src 192.168.0.185
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on wlp0s20f3, link-type EN10MB (Ethernet), capture size 262144 bytes
17:29:53.564131 IP 192.168.0.185 > dlinkrouter: ICMP echo request, id 517, seq 1, length 64
17:29:53.599465 ARP, Reply 192.168.0.185 is-at 00:16:3e:67:d1:4e (oui Unknown), length 46
17:29:54.613213 IP 192.168.0.185 > dlinkrouter: ICMP echo request, id 517, seq 2, length 64
17:29:55.650746 IP 192.168.0.185 > dlinkrouter: ICMP echo request, id 517, seq 3, length 64
17:29:56.684255 IP 192.168.0.185 > dlinkrouter: ICMP echo request, id 517, seq 4, length 64
17:29:58.694523 ARP, Request who-has dlinkrouter tell 192.168.0.185, length 46
17:29:59.732114 ARP, Request who-has dlinkrouter tell 192.168.0.185, length 46
17:30:00.769836 ARP, Request who-has dlinkrouter tell 192.168.0.185, length 46

From what I could tell, it seems like those ARP requests are making it out of the VM since I can see them on host.

Please can you repeat that test, but this time run tcpdump on a specific interface using the -i flag and then track the ARP requests arriving in your VM and VM host and check they are leaving the external interface of the VM host onto the external network.

Outputs with the -i flag on tcpdump

On container

root@con1:/# ping -c 4 192.168.0.1
PING 192.168.0.1 (192.168.0.1) 56(84) bytes of data.

--- 192.168.0.1 ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 3065ms

Monitoring on Ubuntu VM

ajinkya@metaverse:~$ sudo tcpdump -i veth1000_mJBx src 192.168.0.185
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on veth1000_mJBx, link-type EN10MB (Ethernet), capture size 262144 bytes
18:39:17.897460 IP con1 > dlinkrouter: ICMP echo request, id 381, seq 1, length 64
18:39:18.005421 ARP, Reply con1 is-at 00:16:3e:c4:fc:06 (oui Unknown), length 28
18:39:18.914466 IP con1 > dlinkrouter: ICMP echo request, id 381, seq 2, length 64
18:39:19.938724 IP con1 > dlinkrouter: ICMP echo request, id 381, seq 3, length 64
18:39:20.962571 IP con1 > dlinkrouter: ICMP echo request, id 381, seq 4, length 64
18:39:22.946711 ARP, Request who-has dlinkrouter tell con1, length 28
18:39:23.970605 ARP, Request who-has dlinkrouter tell con1, length 28
18:39:24.994548 ARP, Request who-has dlinkrouter tell con1, length 28

ajinkya@metaverse:~$ sudo tcpdump -i br0 src 192.168.0.185
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on br0, link-type EN10MB (Ethernet), capture size 262144 bytes
18:39:17.897460 IP con1 > dlinkrouter: ICMP echo request, id 381, seq 1, length 64
18:39:18.005421 ARP, Reply con1 is-at 00:16:3e:c4:fc:06 (oui Unknown), length 28
18:39:18.914466 IP con1 > dlinkrouter: ICMP echo request, id 381, seq 2, length 64
18:39:19.938724 IP con1 > dlinkrouter: ICMP echo request, id 381, seq 3, length 64
18:39:20.962571 IP con1 > dlinkrouter: ICMP echo request, id 381, seq 4, length 64
18:39:22.946711 ARP, Request who-has dlinkrouter tell con1, length 28
18:39:23.970605 ARP, Request who-has dlinkrouter tell con1, length 28
18:39:24.994548 ARP, Request who-has dlinkrouter tell con1, length 28

Monitoring on Ubuntu Host

ajinkya@ubuntu:~$ sudo tcpdump -i wlp0s20f3 src 192.168.0.185 
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on wlp0s20f3, link-type EN10MB (Ethernet), capture size 262144 bytes
18:39:18.124087 IP con1 > dlinkrouter: ICMP echo request, id 381, seq 1, length 64
18:39:18.233394 ARP, Reply con1 is-at 00:16:3e:c4:fc:06 (oui Unknown), length 46
18:39:19.154488 IP con1 > dlinkrouter: ICMP echo request, id 381, seq 2, length 64
18:39:20.192449 IP con1 > dlinkrouter: ICMP echo request, id 381, seq 3, length 64
18:39:21.229827 IP con1 > dlinkrouter: ICMP echo request, id 381, seq 4, length 64
18:39:23.240194 ARP, Request who-has dlinkrouter tell con1, length 46
18:39:24.277910 ARP, Request who-has dlinkrouter tell con1, length 46
18:39:25.315359 ARP, Request who-has dlinkrouter tell con1, length 46

Oh well there’s your issue, sorry I should have noticed it earlier in your excellent diagram. I only noticed it when I saw wlp0s20f3 as the external interface name on the VM host.

You cannot bridge onto a wifi network, as the MAC address is used for authenticating frames, and the AP doesn’t know about your VM and container.

Instead you can use Ethernet cable or can setup a static route for a different private subnet on your router pointing to your VM host’s IP, and then a static route on your VM host that routes it to your VM. Then inside use a private bridge such as lxcbr0 with the same private subnet.

I used an ethernet cable and changed the interface for configuration. I am able to access containers from the network as well as access internet inside it.

Thank you @tomp

1 Like