By making a bridge in the opensense interfaces you have created a layer2 network. This means that all the devices connected on that network are broadcasting their Mac addresses and are added to the ARP table on the opensense. Since they all are on the same physical network and the same subnet, none of the traffic will ever hit the layer 3 rules on your opensense.

If you want opensense to handle the rules of the traffic you will need to put the devices on different subnets and separate clans. Create a gateway address for every vlan on the opensense and point your devices to the opensense as their gateway.

It sounds like what you're looking to achieve is what's known as zero trust architecture (ZTA). The primary concept is that you never implicitly trust a particular piece of traffic, and always verify it instead.

The most common way I've seen this achieved is exactly what you're talking about - more micro-segmentation of your network.

The design principles are usually centred around what the crown jewels are in your network. For most companies applying ZTA, that's usually their data, especially customer data.

Ideally you create a segment that holds that data, but no processing/compute/applications. You can also create additional segments for more specific use cases if you like, but I've rarely seen this get beyond three primary segments: server; database; data storage (file servers, etc).

In your case, you can either create three separate VLANs on your Proxmox cluster, with your your OPNsense firewall having an interface defined in each, or use the Proxmox firewall. I'd go the former - OPNsense is a lot more capable than the Proxmox firewall, especially if you turn on intrusion detection.

I'm not using any further segmentation beyond my VMs sitting in their own VLAN from my physical, but here's a screenshot of my networking setup on Proxmox. I wrote this reply to another post here on Selfhosted, talking about how my interfaces are setup. In my case, I have OPNsense running as a VM on the same Proxmox cluster. As I said in there, it's a bit of a headfuck getting it done, but very easy to manage once setup.

BTW, ZTA isn't overkill if it's what YOU want to do.

You're teaching yourself some very valuable skills and, and you clearly have a natural talent for thinking both vertically and horizontally about your security. This shit is gold when I interview young techs. One of my favourite interview moments is when I ask about their home setups, and then get to see their passion ignite when they talk about it.

Might want to move the NAS to a separate, unrouted VLAN. Storage only needs local connections and it's good practice not to make it routable.

VLANs all the way. I have several VLANs, including:

• Virtual Servers
• Bare metal
• Trusted devices
• IoT devices
• Guest network etc.

EDIT: An alternative would be to replace or supplement Proxmox with Docker/Podman on the bare metal of the server. The container networking would be isolated by default. If you can replace your VM needs with containers, that may get you what you want.

I would probably put my WLAN on a different subnet/VLAN then the rest of the network, maybe even split it into trusted and guest networks if your AP's support broadcasting multiple SSID's. I don't see anything about NAT/PAT so I assume this isn't going to touch the Internet and just for home brew fuckery.

If you do go down the VLAN route, make sure to define enforce the networks on the Proxmox and firewall side. If you set the VLAN ID on the client instead, an attacker could change it to a different network.

Not sure how exactly Proxmox works for this, but generally you'd distinguish between tagged and untagged ports.
You'd use untagged ports for client/vm access. Any packet gets the VLAN tag set to what you define.
A tagged port would be used to connect Proxmox to the router. This keeps the VLAN tags in packets intact for the routing you'll need to do.

Acronyms, initialisms, abbreviations, contractions, and other phrases which expand to something larger, that I've seen in this thread:

9 acronyms in this thread; the most compressed thread commented on today has 10 acronyms.

[Thread #427 for this sub, first seen 13th Jan 2024, 22:05] [FAQ] [Full list] [Contact] [Source code]

I'm not knowledgeable on communication between VMs and how to best restrict communication there, but I have tried to make my docker networks more secure.

I went a bit overkill for my reverse proxy and all the docker networks it's connected to. For each service I want to expose through my reverse proxy, I manage a network specifically for that service in my caddy docker compose file. I then refer to that external network in my servjce's docker compose file, so that caddy can access it. For example, caddy is on caddy_net-grafana and on caddy_net-homepage. Grafana and homepage are on those networks respectively. So with this setup, caddy can talk to Grafana and homepage, but Grafana and homepage cannot talk to each other.

It wasn't too bad to setup. I made my own conventions for keeping it manageable and it works for me. I did run into the problem where I had to increase the default subnet pool, as after you create like 30 or 31 networks there aren't any subnets left to give out to new docker networks.