Access Control Lists (ACLs)

Access Control Lists (ACLs) control which nodes can communicate within a network. By defining granular rules based on sources, destinations, protocols, and ports, you can enforce security policies across your Camouflage network.

Overview

ACLs provide fine-grained traffic control between nodes in your network. Every rule is evaluated by priority, with lower numbers taking precedence. When ACLs are enabled, the default policy is deny — only traffic explicitly allowed by a matching rule will pass.

Key Features:

• Priority-based rule evaluation (lower number = higher priority)
• Tag-based source and destination matching
• Protocol and port filtering (TCP, UDP, ICMP, or all)
• Allow or deny actions
• Enable/disable rules without deletion

Enabling ACLs

ACLs are disabled by default on new networks. When disabled, all nodes in the network can communicate freely with each other.

To enable ACLs:

1. Navigate to the network detail page in Camouflage Cloud
2. Locate the Access Control Lists section
3. Toggle the ACL switch to On

Once enabled, the default-deny policy takes effect. You must create allow rules for any traffic you want to permit.

Creating Rules

Each ACL rule consists of the following fields:

Field	Description
Priority	Numeric value determining evaluation order. Lower number = evaluated first (e.g., priority 1 before priority 100)
Source	Where traffic originates: a tag (e.g., tag:web), specific node IP, or CIDR range
Destination	Where traffic is sent: a tag (e.g., tag:database), specific node IP, or CIDR range
Protocol	tcp, udp, icmp, or * (all protocols)
Ports	Single port (443), range (8000-9000), comma-separated list (80,443,8080), or * (all ports)
Action	Allow or Deny
Enabled	Toggle to enable or disable the rule without deleting it

Example Rules

Priority: 10
Source: tag:web
Destination: tag:database
Protocol: tcp
Ports: 5432
Action: Allow
Enabled: true

This rule allows TCP traffic on port 5432 from any node tagged "web" to any node tagged "database".

Priority: 20
Source: tag:dev
Destination: tag:prod
Protocol: *
Ports: *
Action: Deny
Enabled: true

This rule denies all traffic from development nodes to production nodes.

Using Tags in Rules

Instead of writing rules for individual node IPs, you can assign tags to groups of nodes and write rules between tags. This approach scales better and simplifies management.

How It Works

1. Create tags in the network's Tags tab (e.g., "web", "database", "dev", "prod")
2. Assign tags to nodes based on their role or environment
3. Write ACL rules referencing tags (e.g., tag:web → tag:database)

When a new node joins and receives the appropriate tag, it automatically inherits the access defined by your tag-based rules.

Example Tag-Based Rules

Allow web servers to reach databases:

Source: tag:web
Destination: tag:database
Protocol: tcp
Ports: 5432
Action: Allow

Deny development environment from production:

Source: tag:dev
Destination: tag:prod
Protocol: *
Ports: *
Action: Deny

Allow all nodes to reach DNS servers:

Source: *
Destination: tag:dns
Protocol: udp
Ports: 53
Action: Allow

Common Patterns

Isolate Development from Production

Create "dev" and "prod" tags and assign them to the appropriate nodes. Then create a high-priority deny rule:

Priority: 1
Source: tag:dev
Destination: tag:prod
Protocol: *
Ports: *
Action: Deny

This prevents any development node from accessing production resources.

Database Access Control

Only allow application servers to reach database nodes on the database port:

Priority: 10
Source: tag:app-server
Destination: tag:database
Protocol: tcp
Ports: 5432
Action: Allow

All other traffic to the database nodes will be denied by the default policy.

Web Server Exposure

Allow all nodes (or external clients) to reach web servers on HTTP/HTTPS:

Priority: 10
Source: *
Destination: tag:web
Protocol: tcp
Ports: 80,443
Action: Allow

Block All Except SSH

With ACLs enabled, create a single allow rule for SSH and let the default-deny policy block everything else:

Priority: 10
Source: *
Destination: *
Protocol: tcp
Ports: 22
Action: Allow

Only SSH connections will be permitted across the network.

Multi-Tier Application

For a typical three-tier architecture:

# Allow frontend to reach backend API
Priority: 10
Source: tag:frontend
Destination: tag:backend
Protocol: tcp
Ports: 8080
Action: Allow

# Allow backend to reach database
Priority: 20
Source: tag:backend
Destination: tag:database
Protocol: tcp
Ports: 5432
Action: Allow

# Deny frontend from directly accessing database
Priority: 5
Source: tag:frontend
Destination: tag:database
Protocol: *
Ports: *
Action: Deny

Note that the deny rule has the lowest priority number (5), so it is evaluated first.

Rule Evaluation

When a packet arrives, the ACL engine evaluates rules in priority order (lowest number first). The first matching rule determines the action:

1. Rules are sorted by priority (ascending)
2. Each rule is checked against the packet's source, destination, protocol, and port
3. The first rule that matches determines whether the packet is allowed or denied
4. If no rule matches, the packet is denied (default policy)

Evaluation Example

Given these rules:

Priority: 10 — Allow tag:web → tag:database, tcp:5432
Priority: 20 — Deny tag:web → *, *:*
Priority: 30 — Allow * → *, tcp:22

Traffic from a web server:

• To database on port 5432 (TCP) — Allowed by rule 10
• To database on port 3306 (TCP) — Denied by rule 20
• To SSH on port 22 (TCP) — Denied by rule 20 (evaluated before rule 30)

Traffic from a non-web node:

• To any node on port 22 (TCP) — Allowed by rule 30
• To any other port — Denied by default policy

Best Practices

1. Use tags liberally — Tag-based rules scale better than IP-based rules
2. Start with high priorities for deny rules — Use low priority numbers (e.g., 1-10) for explicit denies to ensure they're evaluated first
3. Group related rules by priority ranges — For example, use 10-20 for production isolation, 30-40 for service access, etc.
4. Document complex rules — Use the rule description field (if available) or maintain external documentation
5. Test before enabling — In a test environment, enable ACLs and verify connectivity before applying to production
6. Monitor after changes — Watch for unexpected blocked traffic after adding or modifying rules
7. Keep rules simple — Prefer multiple simple rules over one complex rule
8. Use CIDR notation sparingly — Tags are more maintainable than hardcoded IP ranges

Troubleshooting

Traffic is blocked unexpectedly:

• Check rule priority order. A higher-priority deny rule may be matching before your allow rule
• Verify tags are correctly assigned to both source and destination nodes
• Ensure the protocol and port match exactly (e.g., tcp:443 will not match tcp:80)

Rule not taking effect:

• Confirm the rule is Enabled
• Check that ACLs are enabled for the network
• Rules are evaluated in real-time, but allow a few seconds for synchronization across nodes

Cannot reach any nodes after enabling ACLs:

• Remember the default policy is deny. You must create explicit allow rules
• Create a temporary wide-open rule (priority 999, source: *, destination: *, protocol: *, ports: *, action: allow) to restore connectivity while you design proper rules

Next Steps

• Node Tagging Guide — Learn how to create and assign tags for use in ACL rules
• Standalone Daemon Administration — Managing clients in standalone mode