Routing mystery within LXD Container

LXD
1

Greetings. I run Firefox within an LXD container. The host runs Debian 11; the guest runs Ubuntu 20.04. The guest container obtains its IP via routed per Simos’ excellent blog found here: Link.

Now, here is the peculiarity. When I attempt to navigate to my Nextcloud (hosted in another LXD container on a different physical machine) instance via the containerized Firefox, I can do so but the OnlyOffice module within Nexcloud fails.

However, if I navigate to my Nextcloud instance via a non-containerized Firefox run directly in the host machine (Debian 11) or any other machine for that matter, OnlyOffice and Nextcloud work perfectly. (A greater discussion can be found here: help.nextcloud).

It seems to me that the lone difference maker here is that one Firefox is containerized whereas others aren’t. So while the aforementioned help.nexcloud discussion focuses on the OnlyOffice module (to no success so far) I am wondering if any LXD experts can help me understand how traffic is being routed from the LXD container to pretty much any other destination.

Here is my netplan yaml file for the container running Firefox:

network:
    version: 2
    ethernets:
        eth0:
          addresses:
            - 192.168.86.107/32
          nameservers:
            addresses: [192.168.86.79]
          routes:
            - to: 0.0.0.0/0
              via: 169.254.0.1
              on-link: true

Any assistance will be greatly appreciated :slight_smile:

2

As im not familiar with the OpenOffice module I can’t be sure, but things to check will be can you ping the IP of the web service from your firefox container.
Also, be aware that broadcast/multicast traffic cannot be used from inside a container using the routed NIC type, so if there’s any “discovery” protocols being used by the app, these may fail.