Network design. I started my homelab / selfhost journey about a year ago. Network design was the topic that scared me most. To challenge myself, and to learn about it, I bought myself a decent firewall box with 4 x 2.5G NICs. I installed OPNsense on it, following various guides. I setup my 3 LAN ports as a network bridge to connect my PC, NAS and server. I set the filtering to be applied between these different NICs, as to learn more about the behavior of the different services. If I want to access anything on my server from my PC, there needs to be a rule allowing it. All other trafic is blocked. This setup works great so far an I’m really happy with it.
Here is where I ran into problems. I installed Proxmox on my server and am in the process of migrating all my services from my NAS over there. I thought that all trafic from a VM in Proxmox would go this route: first VM --> OPNsense --> other VM. Then, I could apply the appropriate firewall rules. This however, doesnt seem to be the case. From what I’ve learned, VMs in Proxmox can communicate freely with each other by default. I don’t want this.
From my research, I found different ideas and opposing solutions. This is where I could use some guidance.
- Use VLANs to segregate the VMs from each other. Each VLAN gets a different subnet.
- Use the Proxmox firewall to prevent communication between VMs. I’d rather avoid this, so I don’t have to apply firewall rules twice. I could also install another OPNsense VM and use that, but same thing.
- Give up on filtering traffic between my PC, NAS and server. I trust all those devices, so it wouldn’t be the end of the world. I just wanted the most secure setup I could do with my current knowledge.
Is there any way to just force the VM traffic through my OPNsense firewall? I thought this would be easy, but couldn’t find anything or just very confusing ideas.
I also have a second question. I followed TechnoTim to setup Treafik and use my local DNS and wildcard certificates. Now, I can reach my services using service.local.example.com, which I think is neat. However, in order to do this, it was suggested to use one docker network called proxy. Each service would be assigned this network and Traefik uses lables to setup the routes. ’
Would’t this allow all those services to communciate freely? Normally, each container has it’s own network and docker uses iptables to isolate them from each other.
Is this still the way to go? I’m a bit overwhelmed by all those options.
Is my setup overkill? I’d love to hear what you guys think! Thank you so much!
You must log in or register to comment.
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.
This sounds promising. If I understand correctly, you have a ton of networks declared in your proxy, each for one service. So if I have Traefik as my proxy, I’d create traefik-nextcloud, traefik-jellyfin, traefik-portainer as my networks, make them externally available and assign each service their respective network. Did I get that right?
Yup. It works pretty well for me. Just will likely have to increase the default address pool in daemon.json if you go all out.