IncusOS use case capabilities with netbird or headscale / tailscale

IncusOS
1

I have only limited experience with netbird or headscale / tailscale. I read NetBird - IncusOS documentation Tailscale - IncusOS documentation

The netbird docs identify `block_lan_access: If true, block access to local networks when using this peer as a router or exit node.` I can’t find any incusOS tailscale config for allowing exit node traffic.

Can IncusOS cluster or non-cluster be setup with a few IncusOS nodes at different WAN sites, all with netbird `block_lan_access: false`, setup each IncusOS node with container network bridge on netbird as exit node, would this allow for container traffic from site A to be able to communicate with other containers at different IncusOS site B over netbird mesh vpn? Would OVN be or not be required for such such scenario?

Regarding management cli operations I am confused after I read at https://discuss.linuxcontainers.org/t/copying-images-with-unclustered-incusos/26470/4 that communication between nodes can occur by “pull, push or relay”. If nodes can pull or push from to other nodes, is OVN or netbird or headscale / tailscale required or not required for successfully performing certain management operations ie

incus copy remote:container local:container-backup

or cold migrating vm or container across to different incusOS nodes not in same broadcast domain but on different public wan ips?

Merci

2

Regarding management (API) traffic: incus never requires a broadcast domain. Two incus(OS) hosts on public IPs in different subnets can communicate directly. It’s HTTPS so there’s no need for any overlay for this traffic.

The three copy modes are:

  • host A makes a connection to host B (push)
  • host B makes a connection to host A (pull, which is the default)
  • there is no direct A-B connection, but all traffic is relayed via the client (relay)

If there are no firewalls between A and B, then it makes no difference. But if the firewalls don’t permit certain connections, you may have to choose a different mode.

1 Like
3

Hi, ok thanks for confirming again re: management (API) traffic :slight_smile:

That is great feature allowing for lightweight and robust operations.

I assume the netbird and headscale embed services are relatively new and less used so will need to do more testing.

Has anyone already completed setting up multiple IncusOS nodes at different WAN sites and changing core.https_address Address to bind for the remote API (HTTPS) to be hidden behind VPN? When you perform management actions ie incus copy remote:container local:container-backup were the IncusOS nodes successfully directly communicating ie push or pull, or was a third site admin CLI required to relay trasmit the data?

Merci