LXD Container not accessible from LAN

Hi All,
I am new to Linux world and I tried everything I can think off to solve this problem but stuck since so many days. My LXD container is not able to accessible from my LAN.

I tried followings:
https://ubuntu.com/blog/converting-eth0-to-br0-and-getting-all-your-lxc-or-lxd-onto-your-lan

but no help !
Something is wrong and I am not able to make it correct.
Any help would be appreciated !!

if I use only bridged profile somehow my container don’t even get the IP, when I do lxc list ipv4 and ipv6 column are blank.
I tried to change the container netplan configuration with below and container takes the IP but not able to ping 8.8.8.8 or accessible from host machine.

network:
ethernets:
eth0:
addresses:
- 171.17.139.97/28
dhcp4: false
gateway4: 171.17.137.81
version: 2

Note - I am using Hyper-V manager and having window 10 host with ubuntu vm 18.04 created by using quick menu.

Thanks

@girish.meena is this related to your other case?

If so, check that your Windows 10 VM is allowing multiple MAC addresses on its own bridged interface and that the VM’s nic device is set to promiscuous mode to allow it to receive packets that are not for its own MAC address. Otherwise they will not get into the VM to be accessible to LXD.

This might be another benefit of using the ipvlan nic type I mentioned in the other thread, as it will share the host’s MAC address.

@tomp I think my container routing table is not correct. my host VM gateway is 10.91.47.254 and 10.91.47.98 is my host ip4 address on eth0 which got transferred to bridged interface.

Do you see something wrong here?

This is my host route table

@girish.meena unless you’re wanting the host to be a router (which is unlikely seeing as you’ve been asking about bridging up until this point), then the default gateway in the container should be the same IP as on the host, i.e 10.91.47.254. Remember bridging behaves like a switch, so it operated at layer 2, so effectively your container is now on the same network as your host, and so doesn’t need to use your host’s IP to get to the rest of the network.

@tomp corrected it. still not able to ping other network computer from LXD container and vice versa.

Have you checked your HyperV nic allows multiple MACs?

Can you ping the host from your container and vice versa?

Can you ping the host from your container and vice versa? - No, I can’t ping Host WS 2012 and vice versa.
Have you checked your HyperV nic allows multiple MACs? - Hyper V showing different different MAC addr. to all the VMs

How do i do it?

I’m not sure as haven’t used LXD on HyperV before, but it is quite a common issue when running on a virtual machine and using bridging inside the VM, that the nic provided by the VM is filtering multiple MACs and/or not forwarding packets for MACs other than itself.

A quick search brought up this: https://blogs.msdn.microsoft.com/virtual_pc_guy/2011/10/11/an-unusual-reason-to-enable-mac-spoofing/

I’m sure its not for the specific version you run, but describes the problem nicely and hopefully gets you on the right track to solving it.

I don’t have mac spoofing option on VM settings.
I tried to do

ip link set bridge0 promisc on

but no help.

@girish.meena you will need to have the mac spoofing option enabled.

Nothing you change inside the VM itself will make a difference until that is changed (the physical host is likely stopping any traffic from your container’s MAC because it is different than that of the VM).

So you need to allow spoofing.

What version of hyperv do you use?

This looks like a windows 10 equivalent guide https://www.askme4tech.com/advance-features-hyper-v-virtual-network-adapter-part-7

This is on Host Window 2012 R2
image

This is on my laptop
Hyper-V Manager
Microsoft Corporation
Version: 10.0.18362.1

Hey @tomp, I enabled mac spoofing and now
my Windows Host(10.91.41.118) can access the LXD container(10.91.47.65). and vice versa.
I can ping 8.8.8.8 from my LXD container.
I can ping LXD container from my laptop (10.91.68.254) and vice versa.
I can ping Ubuntu 18.04 machine(10.91.47.98, on which we created bridged bridge0) on which LXD container resides. and vice versa.

Does allowing MAC spoofing is security threat? Is it secure to allow it? and Can we run Production system allowing this setting?

Thanks a lot for so much help you provided again and again. Can not believe it got fixed.

Thanks

1 Like

Thats great to hear its working :slight_smile:

Its not a security issue to allow mac spoofing in your VM as long as you trust the workloads running inside your container.

If you were running an untrusted workload then there is the possibility of a container spoofing a MAC of another machine in your network to divert traffic to it, or acting as a rogue DHCP server.

LXD does have some protection for this too in the form of the security filtering modes:

security.mac_filtering boolean false no network Prevent the container from spoofing another’s MAC address
security.ipv4_filtering boolean false no container_nic_ipfilter Prevent the container from spoofing another’s IPv4 address (enables mac_filtering)
security.ipv6_filtering boolean false no container_nic_ipfilter Prevent the container from spoofing another’s IPv6 address (enables mac_filtering)

https://linuxcontainers.org/lxd/docs/master/containers#nictype-bridged