Access Control List (ACL)
Access Control Lists (ACL) define how network traffic is allowed or denied inside a VPC.
Every subnet in a VPC is associated with an ACL, and all Virtual Machines inside that subnet inherit its rules.
ACLs act as a network-level firewall, controlling traffic before it reaches the VM.
What You Can Control with ACLs
With ACL rules, you can control traffic based on:
- Direction
- Ingress - traffic entering resources in the subnet
- Egress - traffic leaving resources in the subnet
- Protocol
- TCP
- UDP
- ICMP (used by
pingand other diagnostics. Defined by an ICMP Type and ICMP Code instead of a port range)
- Source CIDR
- Specific IP ranges (for example,
203.0.113.0/24) - Allow all (
0.0.0.0/0)
- Specific IP ranges (for example,
- Port Range (TCP and UDP only)
- Single ports (e.g.
22,443) - Port ranges (e.g.
3000–4000)
- Single ports (e.g.
- Action
- Allow
- Deny
These rules apply uniformly to all VMs within the subnet.
Traffic that does not match any Allow rule is blocked. To permit a protocol or port, you must add an explicit Allow rule for it.
Default ACL Behavior
When a new VPC is created, CloudRaya automatically applies default ACL rules to ensure basic connectivity.
| Direction | Default rules |
|---|---|
| Ingress | TCP Allow from 0.0.0.0/0 on SSH (22), RDP (3389), HTTP (80), and HTTPS (443) |
| Egress | TCP Allow to 0.0.0.0/0 on all ports (1–65535), and UDP Allow to 0.0.0.0/0 on all ports (1–65535) |
ICMP is not part of the default rules in either direction. As a result, a VM's public IP does not
respond to ping until you add an ICMP rule yourself. This is intentional, it keeps the public IP from
appearing "attached to something" to casual internet scanning. See Allowing Ping (ICMP) to a VM.
You can modify existing rules, add new rules, or remove unnecessary rules to match your security requirements.
Viewing an ACL's Rules
There are two ways to look at the rules on an ACL profile, depending on how much you need to do:
- Quick overview (read-only). On the VPC Detail → Subnet tab, click the ACL name in the ACL Rules column. An ACL Details popup opens showing the Ingress and Egress rules grouped by protocol. This view is for reference only, there is nothing to edit here.
- Full ACL Detail page (editable). Open it from either:
- VM Detail → Network tab → click the ACL name shown next to ACL Rule, or
- VPC Detail → Access List tab → click Detail in the Action column.
The ACL Detail page shows the profile's VPC Name, ACL Name (with a pencil to rename it), Network Address, and the number of Subnets using it, followed by the Ingress and Egress tabs. Under each tab, rules are grouped into TCP Protocol, UDP Protocol, and ICMP Protocol tables.
Editing ACL Rules
All rule changes are made on the ACL Detail page. Pick the Ingress or Egress tab first, then use the actions below. Because a profile can be shared, changes apply to every subnet currently using it.
Adding a Rule
- On the Ingress or Egress tab, click Add Ingress (or Add Egress).
- In the dialog, choose:
- Protocol -
TCP,UDP, orICMP - Action -
AlloworDeny - Source CIDR - click Allow All to fill
0.0.0.0/0, click the subnet name button to fill the subnet's own CIDR, or type a specific CIDR in the field (one CIDR per rule, see Choosing a Source CIDR) - For TCP/UDP: Start Port and End Port (use the same value in both for a single port)
- For ICMP: ICMP Type and ICMP Code
- Protocol -
- Click Save.
Choosing a Source CIDR
The Source CIDR field accepts one CIDR per rule. Pick the CIDR that matches who should be allowed:
| You want to allow | Use | Example |
|---|---|---|
| One specific IP address | /32 | 198.51.100.25/32 |
| A block of addresses | A shorter prefix, such as /24 | 203.0.113.0/24 |
| Everyone | Allow All | 0.0.0.0/0 |
| Several IPs or blocks that are far from each other | One rule for each CIDR | see below |
A smaller number after the slash means more IP addresses are allowed. Choose the smallest block that you need.
If the IP addresses are not in one block, add one rule for each. For example, to let an office IP and a home IP connect to a VM with SSH:
- On the Ingress tab, click Add Ingress.
- Set Protocol to
TCP, Action toAllow, Source CIDR to198.51.100.25/32, and Start Port and End Port to22. Click Save. - Click Add Ingress again and repeat with Source CIDR
203.0.113.40/32.
Both rules are in the same ACL profile, so they work for every subnet that uses this profile.
Editing or Deleting a Rule
- Edit - click the pencil icon on a rule row. The Edit Ingress Rule dialog opens with the same fields. Adjust them and click Update.
- Delete - click the trash icon on a rule row, then confirm with Delete Rule. A deleted rule cannot be recovered.
Reordering Rules
Click Reorder Ingress (or Reorder Egress) to enter drag-and-drop mode, then drag rows to change
their priority and click Save Rules. Rules are evaluated in order, so ordering matters when you
combine broad Allow rules with narrower Deny exceptions.
After Saving
Rule changes are processed in the background (you'll see a Processing notification and a the VPC is in progress banner). Wait until the new rule appears in the list, then verify from your VM or application that the access behaves as expected. If it still doesn't work after the change has finished processing, contact support.
Allowing Ping (ICMP) to a VM
By default a VM's public IP does not answer ping (you get Request timed out), because the default
ACL has no ICMP rule. To enable it, add an Ingress ICMP rule to the subnet's ACL:
- Open the ACL Detail page for the ACL attached to the VM's subnet (see Viewing an ACL's Rules).
- On the Ingress tab, click Add Ingress.
- Set:
- Protocol:
ICMP - Action:
Allow - Source CIDR: click Allow All for
0.0.0.0/0(anyone can ping), or enter a specific CIDR to limit who can ping the VM - ICMP Type:
8 - ICMP Code:
0
- Protocol:
- Click Save and wait for the rule to appear in the ICMP Protocol table.
The VM's public IP now responds to ping.
When you no longer need it, delete the ICMP rule to return the public IP to its non-pingable state.
Creating an ACL Profile
Each VPC keeps its own list of ACL profiles. You can create a new one and attach it to one or more subnets later.
Start from either:
- VPC Detail → Access List tab → Add ACL, or
- VPC Detail → Subnet tab → the pencil (Change ACL) in the ACL Rules column → open the ACL dropdown → + New ACL Rules
Both open the Add ACL page:
- Step 1 - VPC is fixed to the VPC you started from.
- Step 2 - ACL Rules:
- Enter an ACL Name.
- The Rule List starts pre-filled with the default rules. Use Add Rule to add more (same dialog as Adding a Rule), the pencil/trash icons to edit or remove rows, and drag handles to reorder. Reset Default Rules restores the starting set.
- Click Save to keep the rule list.
- Click Add ACL to create the profile.
The new profile appears on the Access List tab with no subnet attached yet (shown as -). Attach it
from the Subnet tab, see Changing the ACL Attached to a Subnet.
ACL Profiles Are Reusable
An ACL is not locked to a single subnet forever. Each VPC can have multiple ACL profiles, and the same profile can be attached to more than one subnet at the same time.
This is useful when several subnets serve the same application or have identical access requirements. You can define the rules once and reuse the same profile, instead of recreating identical rules for each subnet.
Because a profile can be shared, editing its rules affects every subnet currently using it, not just one.
Changing the ACL Attached to a Subnet
You can change which ACL profile a subnet uses at any time, without recreating the subnet.
Steps
- Go to Dashboard → Network → VPC
- Click View Detail on the relevant VPC
- On the Subnet tab, click the pencil (Change ACL) icon in the subnet's ACL Rules column
- In the Change ACL dialog, the current subnet and ACL are shown at the top. Use the ACL dropdown to pick a different profile, or click + New ACL Rules to create one.
- Click Update VPC
Viewing Which Subnets Use an ACL Profile
The Access List tab on the VPC Detail page lists every ACL profile created for that VPC, along with the subnet(s) currently attached to each one.
Use this view to check which subnets would be affected before editing a shared ACL profile.
ACL Profiles Are Scoped to a VPC
ACL profiles belong to the VPC they were created in. A profile created in one VPC cannot be attached to a subnet in a different VPC, even within the same Cloud Zone. Each VPC maintains its own independent list of ACL profiles.
How ACLs Work with Virtual Machines
ACLs operate at the VPC subnet level, not at the individual VM level.
This means:
- VMs do not have their own ACLs
- All VMs in the same subnet share the same ACL rules
- Changing an ACL affects all VMs attached to that subnet
For VM-specific firewall configuration (such as application ports or OS-level filtering), you should configure firewall rules inside the operating system.
📄 See: VM Networking Basics
Ingress vs Egress Rules
| Rule Type | Controls | Example |
|---|---|---|
| Ingress | Traffic entering the subnet | Allow HTTP (80) from the internet |
| Egress | Traffic leaving the subnet | Allow outbound access to external APIs |
Best practice is to:
- Keep ingress rules restrictive
- Allow only the ports your application actually needs
- Monitor and tighten egress rules when required
Common Use Cases
- Allow SSH access only from a specific office IP, or from several IPs with one rule for each (see Choosing a Source CIDR)
- Expose web applications using ports 80 and 443
- Allow
pingfor monitoring by adding an ICMP rule - Block unnecessary outbound traffic
- Separate public-facing and internal workloads using different subnets and ACLs
Important Notes
- ACL rules are evaluated at the network level
- Incorrect rules may block access to all VMs in a subnet
- Always review ACL changes carefully before applying them in production environments
- Reused ACL profiles affect every subnet attached to them. Check the Access List tab before editing a shared profile