scaleway · RoRoJ · Mar 31, 2025 · Mar 26, 2025 · Mar 26, 2025 · Mar 26, 2025
diff --git a/menu/navigation.json b/menu/navigation.json
@@ -3078,6 +3078,10 @@
                     "label": "Understanding DNS",
                     "slug": "dns"
                   },
+                  {
+                    "label": "Understanding NACLs",
+                    "slug": "understanding-nacls"
+                  },
                   {
                     "label": "Getting the most from Private Networks",
                     "slug": "getting-most-private-networks"

@@ -62,6 +62,14 @@ Internet Protocol Version 6 is the most recent version of the IP protocol used f
 
 When an IPv6-compatible resource is attached to a Private Network, it has a private IPv6 address on that network. Scaleway Private Networks' [DHCP](#dhcp) functionality assigns this private IPv6 address when the resource joins the network. Alternatively you can reserve and attach an IP address of your choice with [IPAM](/ipam/how-to/reserve-ip/).
 
+## Network ACL
+
+<Message type="important">
+NACLs are currently in Public Beta, and configurable only via the [VPC API](https://www.scaleway.com/en/developers/api/vpc/) and developer tools. This feature will be coming soon to the Scaleway console.
+</Message>
+
+A VPC's Network **A**ccess **C**ontrol **L**ist is composed of stateless rules to control the flow of traffic between Private Networks. By default, the list contains no rules, and therefore traffic is allowed to flow unrestrictedly between the VPC's Private Networks. Add rules to the list to start creating restrictions. [Take a deeper dive into NACLs](/vpc/reference-content/understanding-nacls/).
+
 ## Private IP address
 
 A [private IP address](/vpc/how-to/attach-resources-to-pn/#how-to-view-the-resources-ip-address) identifies a resource on a Private Network. When you attach a resource (e.g. an Instance) to the network, you can either [use a reserved IP address](/ipam/how-to/reserve-ip/), or let [DHCP](#dhcp) assign one IPv4 and (if the resource is IPv6-compatible) one IPv6 address from the designated [CIDR blocks](#cidr-block) to that resource.

@@ -46,6 +46,18 @@ This is not currently possible. You may consider using a VPN tunnel to achieve t
 
 Managed Databases do not currently support VPC routing - see our [dedicated documentation](/vpc/reference-content/understanding-routing/#limitations)
 
+### Can I control traffic flow between my VPC's Private Networks?
+
+Yes, use the [Network ACL feature](/vpc/how-to/manage-nacl) to filter packets flowing between the different Private Networks of your VPC. By default, all traffic is allowed to pass, until you start to add rules to the VPC's NACL.
+
+<Message type="important">
+NACLs are currently in Public Beta, and configurable only via the [VPC API](https://www.scaleway.com/en/developers/api/vpc/) and developer tools. This feature will be coming soon to the Scaleway console.
+</Message>
+
+## How are NACLs different from security groups?
+
+[Security groups](/instances/how-to/use-security-groups/) filter **public** traffic on your Instances, whereas NACLs filter traffic to/from Private Networks only.
+
 ## Private Networks
 
 ### What are Private Networks?

@@ -6,9 +6,9 @@ meta:
 
 <Alert
   sentiment="info"
-  title="VPC Basic Use Case"
+  title="Network Access Control List"
 >
-  Read our [Basic VPC use case](/vpc/reference-content/use-case-basic/) documentation for full details of how to create a simple infrastructure that leverages the advantages of Private Networks, including accompanying Terraform/OpenTofu templates.
+  Network Access Control Lists (NACLs) are now in Public Beta, allowing you to control routing between the Private Networks of your VPC. Currently, NACLs are configurable only via the [VPC API](https://www.scaleway.com/en/developers/api/vpc/) and developer tools. This feature will be coming soon to the Scaleway console.
 
 </Alert>
 

@@ -0,0 +1,109 @@
+---
+meta:
+  title: Understanding Network ACLs
+  description: Learn how to Network Access Control Lists (NACL) filter inbound and outbound traffic between the different Private Networks of your VPC. Understand concepts, best practices, and key use cases.
+content:
+  h1: Understanding Network ACLs
+  paragraph: Learn how to Network Access Control Lists (NACL) filter inbound and outbound traffic between the different Private Networks of your VPC. Understand concepts, best practices, and key use cases.
+tags: vpc nacl network-access-control-list default-rule stateless inbound outbound port
+dates:
+  validation: 2025-03-26
+  posted: 2025-03-26
+categories:
+  - network
+---
+
+<Message type="important">
+NACLs are currently in Public Beta, and configurable only via the [VPC API](https://www.scaleway.com/en/developers/api/vpc/) and developer tools. This feature will be coming soon to the Scaleway console.
+</Message>
+
+Every VPC has a Network **A**ccess **C**ontrol **L**ist (NACL). This list is composed of stateless rules to control the flow of traffic between the Private Networks of the VPC. By default, at first, the list contains no rules, and therefore traffic is allowed to flow unrestrictedly. You can add rules to restrict traffic flow according to your requirements.
+
+This document sets out general information and best practices about Scaleway VPC NACLs.
+
+## Network ACL overview
+
+Every Scaleway VPC has a Network ACL. In its initial state, it contains no rules. Thanks to [managed routing](/vpc/reference-content/understanding-routing/), which automatically routes traffic between Private Networks, traffic is freely routed between the Private Networks of the VPC.
+
+When you start adding rules to your NACL, traffic flow is restricted between certain sources and destinations within the VPC, according to the rules you set. A default rule is added to the NACL, which dictates the action to take on traffic that does not match any rules in the list: it can either be **allowed** or **denied**.
+
+<Lightbox src="scaleway-nacl-diag-simple.webp" alt="A schema shows how the NACL sits at the intersection of two Private Networks in a Scaleway VPC" />
+
+NACL rules are stateless, meaning that the state of connections is not tracked, and return traffic is not automatically allowed, just because the outbound request was allowed. Explicit rules are required for each direction of traffic.
+
+NACLs only control traffic as it enters or exits the Private Network(s) of a VPC. They do not:
+- Filter traffic between resources attached to the same Private Network
+- Filter traffic from/to the public internet (for this, use [security groups](/instances/how-to/use-security-groups/) for Instances, or equivalent features for [other resource types](/ipam/reference-content/)).
+
+The diagram below shows how a NACL allows an Instance on Private Network A to send a packet to an Instance on Private Network.
+
+However, an Instance on Private Network B is blocked from sending a packet to an Instance on Private Network A, because no specific rules allow it to do so, and the default rule is set to `Deny`.
+
+<Lightbox src="scaleway-nacl-diag-detail.webp" alt="A schema shows how the NACL sits at the intersection of two Private Networks in a Scaleway VPC. Packets attempt to travel between Private Networks, and are either allowed or denied according to NACL rules" />
+
+## NACL rule configuration
+
+When defining an NACL rule, you must enter the following settings:
+
+- **IP version**: Either IPv4 or IPv6. The rule will apply only to traffic matching this IP version, meaning that in effect, each VPC has two NACLs: one for IPv4 and one for IPv6. If you want to create an equivalent rule for the other IP version, you must do so separately.
+
+- **Protocol**: Either `TCP`, `UDP`, or `ICMP`. The rule will apply only to traffic matching this protocol. Alternatively, you can choose to apply it to traffic matching any protocol.
+
+- **Source** and **destination**: The rule will apply to traffic originating from this source and being sent to this destination. For both, enter an IP range range in [CIDR format](/vpc/concepts/#cidr-block), and a port or port range. Alternatively, you can opt for the rule to apply to all IPs and/or all ports.
+
+- **Action**: The NACL will either **Allow** (accept) or **Deny** (drop) traffic that matches the rule, to proceed to its destination.
+
+## Rule priority and application
+
+The Network Access Control List should be read from top to bottom. Rules closer to the top of the list are applied first. If traffic matches a rule for an **Allow** or **Deny** action, the action is applied immediately. That traffic is not then subject to any further filtering or any further actions by any rules that follow. 
+
+## Statelessness
+
+**NACL rules are stateless**. This means the state of connections is not tracked, and inbound and outbound traffic is filtered separately. Return traffic is not automatically allowed, just because the outbound request was allowed. Explicit rules are required for each direction of traffic.
+
+Therefore, if you create a rule to allow traffic in one direction, you may also need a separate rule to allow the response in the opposite direction. 
+
+## Default rule
+
+Each NACL must have a default rule, which applies its action to all traffic that did not match any other rules in the list.
+
+Best practice is to set your default rule to **Deny**, and use the **Allow** action for all other rules. This way, you have fine-grained control over the traffic allowed to flow, and all other traffic is blocked by default.
+
+Nonetheless, you can choose to set your default rule to **Allow** if you wish. In this case, all other rules in the list should use the **Deny** action, to filter out the specific traffic you want to block. All other traffic will be permitted by the default rule.
+
+## NACL example
+
+The table below shows an example of an NACL for IPv4 traffic:
+
+<Lightbox src="scaleway-nacl-example.webp" alt="A table shows a number of NACL rules" />
+
+- A number of TCP rules allow connections to the specific ports necessary for SSH, HTTP, and HTTPS traffic. These rules allow all IPv4 sources within the VPC to connect to these ports, for all IPv4 destinations. 
+
+- An ICMP rule allows all ICMP traffic from/to all IPv4 addresses on all ports, effectively permitting all ping requests within the VPC to function.
+
+- A TCP rule allows PostgreSQL access on port 5432 from one Private Network (172.16.2.0.5/22) to another Private Network (172.16.8.0/22). An **inverse rule** also allows PostgreSQL access from Private Network B to A.
+
+- A TCP rule allows connections from all IPv4 sources to all IPv4 destinations on the port range `32768-65535`, effectively allowing all return (incoming) traffic towards ephemeral ports.
+
+- The default rule blocks all traffic not explicitly allowed by one of the rules above.
+
+## NACL limitations
+
+Network ACLs cannot be used to block or filter the traffic to or from the following:
+
+- Scaleway DNS
+- Scaleway DHCP
+- Scaleway Instance metadata
+- Kubernetes Kapsule task metadata endpoints
+- License activation for Windows installation on Elastic Metal or Instances 
+
+NACLs have the same resource limitations as [VPC routing](/vpc/reference-content/understanding-routing/#limitations), they cannot currently be used to filter Managed Database traffic, though this functionality is planned for the future.
+
+NACLs are currently available only via the Scaleway API and developer tools. They are not yet available in the Scaleway console.
+
+## NACL quotas
+
+NACL quotas are as follows:
+
+- A maximum of 255 rules for IPv4 (per VPC)
+- A maximum of 255 rules for IPv6 (per VPC)