ACL's for very specific subnet isolation

[Andrew_Wilson]

Hi:

I have a debian VM (subnet 172.17.1.1/24) with four containers running in it:

+----------------+---------+---------------------+------+-----------+-----------+
|      NAME      |  STATE  |        IPV4         | IPV6 |   TYPE    | SNAPSHOTS |
+----------------+---------+---------------------+------+-----------+-----------+
| Nextcloud      | RUNNING | 172.17.1.193 (eth0) |      | CONTAINER | 12        |
+----------------+---------+---------------------+------+-----------+-----------+
| OGSelfHosting  | RUNNING | 172.17.1.19 (eth0)  |      | CONTAINER | 9         |
+----------------+---------+---------------------+------+-----------+-----------+
| SysAdmin-22-04 | RUNNING | 172.17.1.102 (eth0) |      | CONTAINER | 10        |
+----------------+---------+---------------------+------+-----------+-----------+
| haproxy        | RUNNING | 172.17.1.230 (eth0) |      | CONTAINER | 0         |
+----------------+---------+---------------------+------+-----------+-----------+

The VM itself has access to 172.16.50.1/24 (which I need), but I have isolated the containers so they only have internet access AND, currently, access to the subnet of the vm (172.17.1.1/24), which is not quite what I want but I am a little stuck. Ideally, I want the haproxy reverse proxy container to be able to access the other three containers so it can direct web traffic TO the other three containers, but I can either get it so they can either all talk to each other - OR none of them can talk to each other. I want slightly better fidelity, if it’s possible.

Here’s my public-only ACL, which I stole unashamedly from one of Stephane’s posts (thank you!):

name: public-only
description: ""
egress:
- action: allow
  state: enabled
- action: allow
  destination: 172.17.1.0/24
  state: enabled
- action: reject
  destination: 10.0.0.0/8
  state: enabled
- action: reject
  destination: 192.168.0.0/16
  state: enabled
- action: reject
  destination: 172.16.0.0/12
  state: enabled
ingress:
- action: allow
  state: enabled
config: {}
used_by:
- /1.0/networks/incusbr0
project: default

I tried modifying the above public-only acl by adding ‘source 172.17.1.230’, which intuitively is what I think I want (see below), but unsurprisingly it didn’t work - I can still ping from any container to any other, and I am a little lost on how to achieve my desired level of isolation (if it’s possible). Can I modify this (how) or do I need a different acl? Can someone syntax point me or advise please?

name: public-only
description: ""
egress:
- action: allow
  state: enabled
- action: allow
  source: 172.17.1.230    # <<--my attempt at further isolation
  destination: 172.17.1.0/24
  state: enabled
- action: reject
  destination: 10.0.0.0/8
  state: enabled
- action: reject
  destination: 192.168.0.0/16
  state: enabled
- action: reject
  destination: 172.16.0.0/12
  state: enabled
ingress:
- action: allow
  state: enabled
config: {}
used_by:
- /1.0/networks/incusbr0
project: default

Thank you!

Andrew

[stgraber (Stéphane Graber)]

You are using a regular Incus bridge (incusbr0), so firewalling can only apply to traffic in and out of that bridge, not traffic between the members of the bridge.

There is an attempt at changing that here: Support for ACLs for bridge NIC device when using nftables driver. by mikerobski · Pull Request #1225 · lxc/incus · GitHub

But until that gets reviewed, tweaked and merged, you can only do micro-segmentation through OVN.

[Andrew_Wilson]

OK, thank you for clarifying.

[chuckboecking]

Please note:

Network Isolation by Project on Single Server Incus Host

Hi Team, I have a single incus host server (not clustered). I want to be able to isolate instances (from a networking perspective) to only communicate with containers in the same project and still be able to communicate with the outside world. My assumption is that you can create a bridged network per project; however, I do not know the best way to prevent communication between network bridges. This instance will most likely have 10+ projects. If the host firewall needs to control communicatio…

Below is a more concise example of using iptables to allow containers/vms of one bridge to talk containers/vms/ on another (specific) bridge:

Incus Linux containers for dummies

I believe it is worth reviewing this thread as well: https://discuss.linuxcontainers.org/t/network-isolation-by-project-on-single-server-incus-host/ It talks demonstrates how you can create a new bridge and quickly isolate traffic between containers on that bridge. Here is a quick example: Block traffic between all incus bridges (note the wildcard ‘+’): sudo iptables -A FORWARD -i incusbr+ -o incusbr+ -j REJECT Allow for exceptions if needed: sudo iptables -A FORWARD -i incusbr4 -o incusbr…

This solution is probably not as concise as you want; however, it gives you some degree of control.

Does this help?