I want to enhance my security and so i started to segment my network.

I have set up these vlans:

1: mgmt (where unraid host listening)

9: home

10: iot

20: server

30: dmz

40: guest

My unraid host has 4 interfaces 2x10Gbe, 2x2,5Gbe

For now eth0 is a 10Gbe interface (the other is passed through to security onion vm as monitoring interface

The 2,5 Gbe interfaces are not used (except one for vpro which doesn't play nice if using it for "classic" network).

I created subinteraces in vlan on eth0 (eth0.10, eth0.20, eth0.30)

I don't use bond or bridge in network settings.

I use docker macvlan (cool for observability) and host access to custom network.

With these settings i should have vhost0 as default interface for vm. But i can choose between eth0 or vibr0 (i don't understand the interest of that one)

However vhost0 (as well as vhost0.10,...) exists but are not selectable.

This was not the case with unraid 6.12.x where vhost0 was used as parent interface for vm.

vhostX interfaces have the same mac@ than parent interface and unifi network server (and other network stuff) doesn't like that.

As i understand vhost interface is the way virtio-net driver handle network connection for the guest os.

So why unraid (since V7 i think) offers eth interfaces to vm ?

For the apps published what would you use:

a docker bridge on eth0.10 or a macvlan on eth0.10?

For those containers in a stack i'll use several networks depending on the service (frontend, backend).

Unraid Networking (VLANs & Interfaces in V7.x)

Your Setup Recap:

• eth0: Active 10GbE interface, trunked with VLANs (home=10, server=20, dmz=30, etc.)

• eth1: 10GbE passthrough to Security Onion

• eth2, eth3: 2.5GbE mostly unused, one reserved for vPro

• Docker: Using macvlan, with VLAN subinterfaces (eth0.10, etc.)

• VMs: Seeing eth0 and virbr0, but not vhost0 or vhost0.x in the GUI

Why does Unraid expose eth0 instead of vhost0 to VMs now?

Yes—Unraid 7.x has changed how it exposes interfaces for VM bridging. Here's what you need to know:

• In 6.12.x and before, Unraid handled VM bridges with br0 or vhost0.

• Starting with 7.x, Unraid exposes raw interfaces (ethX) and leaves bridge creation to you or to libvirt manually.

• vhost0 and its siblings are virtual interfaces created on the fly per VM using virtio, not something meant to be manually selected—they aren’t persistent.

• virbr0 is a NAT bridge used by libvirt for isolated VM networks (uncommon in Unraid).

*This is actual a reman of older network configuration. new unraid configs will use shim-br0

Fix: If you want VLAN-aware bridges for VMs (like br0.10), you need to manually define them or use brctl or ip link to create them outside the GUI. Some users now manually create br0.10, br0.20, etc. mapped to eth0.X.

MAC Address Conflicts with macvlan

You're right—macvlan networks replicate the MAC address of the parent interface, which causes:

• Duplicate MAC detection

• Broken connectivity on networks with strict switch/router policies (e.g., UniFi)

This is a known issue with Unraid's Docker macvlan mode. As of now:

• macvlan ≠ friendly with host ↔ container communication

• ipvlan is better for observability and host access if you can tolerate containers not having unique MACs

While I Prefer macvlan and have other script... Ipvlan may suit your needs here...

Review: https://forums.unraid.net/topic/178033-bmartino1-user-scripts/#findComment-1492333

Apps Published (macvlan vs bridge)?

For apps that serve clients on your LAN (frontend, dashboard, APIs):

• macvlan on eth0.10: Allows containers to be treated like separate devices on the VLAN. Better for visibility (e.g., firewalls, metrics) and VLAN rules.

For internal/backend services that don’t need direct LAN access:

• docker bridge is fine and simpler. Use --internal networks if you want to harden them further.

You can mix:

• frontend_net (macvlan on eth0.10)

• backend_net (bridge)

• db_net (internal bridge)
  Use docker-compose or podman to connect containers to multiple networks cleanly.

Most of your isseus seem to stem from linux misuinderstadnign from a taged interface vs untage interface...

so br0 being the unraid default interface.
by default before any vlan configuratiosn. all traffic is on vlan1

IF I want unraid to access vlan2 I need to add it in the web ui at enable vlan add vlan...
this should make a tagged interface br0.2 not the ".2" this is linux networking vlan tagging...

UNRIAD IS NOT NETWORKING EQUIPMENT!
this is a common layer 2 / layer 3 cross talk issue...

without knowing more of you network gin hardware I can only give you examples and base guid info...

reveiw:

https://forums.unraid.net/topic/147455-support-unifi-controller-unifi-unraid-reborn/page/11/#findComment-1384213

https://forums.unraid.net/topic/188695-docker-network-issue/#findComment-1541042

https://forums.unraid.net/topic/191099-networking-for-a-container/#comment-1560951

https://forums.unraid.net/topic/190501-unraid-in-unifi/page/2/#comment-1558327

Edited June 21, 20251 yr by bmartino1

thank you for your answer. I didn't had the notification. I will add comments tomorrow.

i had not seen the networking changes in 7 but now it makes more sense.

I have more work to do to have my server properly setup. It's a long process as i move from a flat network to segmented one. I have to figure out where to put the devices and the services.

I think i will also transition to portainer with stacks to have better control of docker networks (like in compose but with a nice gui)

But as i have over 70 running containers it's quite long to test.