Thanks, that’s a great write up. One thing I didn’t ubderstand however is in your Docker macvlan, you set the parent to br0.10 and br0.20, where are those parents defined?

Maybe I misunderstood the macvlan documents but what I did was defining a vlan in server netplan vlan0.100 and set the macvlan parent to that vlan0.100. Is that not how it’s supposed to be?

I will post it when I get my hands on it, but basically I made a macvlan which is using the server vlan, and then in the compose I set the network to that macvlan, which seems to be functional at least

Thanks for sharing this, I’ll give it a try and see how it goes

I mean at the moment I don’t have any bridges setup (other than the dockers own bridge) I thought maybe I could solve my issue with bridging

That is my gut feeling too, but as I mentioned in another comment all physical devices work fine in their respective subnet. This is happening before I move the containers to a new subnet, and before these changes everything was working fine.

Answer to your first question, he dockers successfully resolve and access internet

2. Yes the OPNSense is the primary router and dhcp provider so all the subnets and vlans are defined and working with physical devices

I actually was having the same issue with the routing of server. How did you setup your bridge exactly? Do you mind sharing your netplan?

I apologize if my comment came off as an attack, that was not my intention.

I appreciate you putting in the effort to bring up a concern, but I still don’t get it.

Hope you enjoy your weekend

I not sure what you are trying to argue.

Even if you audit the code yourself, you still need to trust your OS, you need to trust the hardware the OS is running on, and you need to trust the proprietary drivers of each component in that hardware. Then at that point you gotta trust the person who sold you the hardware hasn’t modified it.

Ok and?