fix(vpc): continue routing modifs

Author: RoRoJ

pages/vpc/how-to/manage-routing.mdx

@@ -66,21 +66,6 @@ Follow the steps below to update routing behavior for a given VPC:
 
 Your VPC's routing behavior is updated, and you are directed to its routing table. Custom routes will now be scoped to the entire VPC, and you can use the **Manage default routes** button if you want to select Private Networks to receive default routes from throughout the VPC.
 
-## How to generate a managed route
-
-Two types of auto-generated routes exist for VPCs:
-
-- **Local subnet route**: Generated when you create a Private Network in a VPC. Allows traffic to be routed between different Private Networks in the VPC.
-- **Default route to internet**: Generated when you attach a Public Gateway to a Private Network in the VPC, and set it to advertise a [default route](/public-gateways/concepts/#default-route). Allows traffic to be routed to addresses outside the VPC (i.e. the public internet) via the gateway. 
-
-<Message type="note">
-By default, Public Gateways remain scoped to the Private Network(s) to which they are attached. They do not, as standard, advertise the default route on other Private Networks in the VPC. 
-
-However, each Private Network can opt in to receive default route advertisements from across the entire VPC, rather than only from locally attached gateways. This allows them to find a route to the internet even if there is no Public Gateway or default custom route on their own Private Network. See our [dedicated documentation](TODO) for full details. 
-</Message>
-
-You cannot delete managed routes, as their lifecycle is fully managed by Scaleway. The route will be automatically deleted for you when you delete the Private Network or Public Gateway that it concerns.
-
 ## How to access and read the route table
 
 Your VPC's **route table** can be found in its **Routing** tab. The route table shows all the existing routes for the VPC.
@@ -103,6 +88,21 @@ Your VPC's **route table** can be found in its **Routing** tab. The route table
 
     For help with understanding the route table and how to read it, [refer to our documentation about route tables](/vpc/reference-content/understanding-routing/#route-table).
 
+## How to generate a managed route
+
+Two types of auto-generated routes exist for VPCs:
+
+- **Local subnet route**: Generated when you create a Private Network in a VPC. Allows traffic to be routed between different Private Networks in the VPC.
+- **Default route to internet**: Generated when you attach a Public Gateway to a Private Network in the VPC, and set it to advertise a [default route](/public-gateways/concepts/#default-route). Allows traffic to be routed to addresses outside the VPC (i.e. the public internet) via the gateway. 
+
+<Message type="note">
+By default, Public Gateways remain scoped to the Private Network(s) to which they are attached. They do not, as standard, advertise the default route on other Private Networks in the VPC. 
+
+However, each Private Network can opt in to receive default route advertisements from across the entire VPC, rather than only from locally attached gateways. This allows them to find a route to the internet even if there is no Public Gateway or default custom route on their own Private Network. See our [dedicated documentation](TODO) for full details. 
+</Message>
+
+You cannot delete managed routes, as their lifecycle is fully managed by Scaleway. The route will be automatically deleted for you when you delete the Private Network or Public Gateway that it concerns.
+
 ## How to manage default route scope
 
 If your VPC is using [up-to-date routing behavior](#how-to-update-routing-behavior), you can enable each Private Network to receive default route advertisements not only from their locally attached Public Gateways, but also from throughout the VPC.

pages/vpc/reference-content/understanding-routing.mdx

@@ -7,7 +7,7 @@ content:
   paragraph: Explore the fundamentals of VPC routing with Scaleway. Understand how to manage traffic flow and optimize network routes within your Virtual Private Cloud
 tags: vpc routing route-table private-network managed-route automatic-route local-subnet-route default-route
 dates:
-  validation: 2024-12-03
+  validation: 2025-05-02
   posted: 2024-05-28
 categories:
   - network
@@ -19,11 +19,11 @@ VPC routing allows resources and Private Networks in the same VPC to communicate
 
 When you create a Private Network, a managed route is automatically created and added to the VPC’s route table. This route allows the VPC to automatically route packets to resources attached to that Private Network, even if they originate from a resource attached to a different Private Network on the VPC.
 
-Managed routes are also automatically added to the VPC’s routing table when you attach a Public Gateway to a Private Network, and tell it to advertise the default route. This type of managed route allows traffic on the given Private Network to be forwarded to addresses outside the VPC (i.e. the public internet) via the Public Gateway.
+Managed routes are also automatically added to the VPC’s routing table when you attach a Public Gateway to a Private Network, and tell it to advertise the default route. This type of managed route allows traffic to be forwarded to addresses outside the VPC (i.e. the public internet) via the Public Gateway.
 
 You can create your own custom routes to send traffic for defined IP ranges towards a specified resource in the VPC, for example if you want to route to a VPN installed on an Instance.
 
-Routing is activated by default whenever you create a new VPC, and can be activated on pre-existing VPCs by [following these steps](/vpc/how-to/manage-routing/#how-to-activate-routing). More routing features are planned for the future, such as ACLs and firewalling.
+Routing is activated by default whenever you create a new VPC, and can be activated on pre-existing VPCs by [following these steps](/vpc/how-to/manage-routing/#how-to-activate-routing). Network ACLs, to finely control and filter VPC traffic, are available [via the API](/vpc/reference-content/understanding-nacls) (currently in Public Beta).
 
 The diagram below shows an example of how routing works across two Private Networks on a VPC. The route table is held on the VPC's virtual router ([VRouter](/vpc/concepts/#vrouter)), and synched to each resource as it joins a Private Network. 
 - An Elastic Metal server on Private Network A can send a packet to the public internet via a Public Gateway also attached to Private Network A.
@@ -44,10 +44,7 @@ Every VPC has an associated **route table**, used to manage and control the rout
     - For custom routes, the next hop is a defined resource on a defined Private Network.
     - If the destination IP is not known on the VPC (represented by the `0.0.0.0/0` address), its next hop will be a Public Gateway so that it can reach the public internet (as long as a Public Gateway set to advertise the default route has been attached to the Private Network).
 - A **description**. This helps to describe the type of route, e.g. `Local subnet route` for routes to Private Networks, or `Default route to internet` for routes to Public Gateways, or a user-defined description for custom routes.
-
-<Message type="important">
-Public Gateways remain scoped to the Private Network(s) to which they are attached. They do not advertise the default route on other Private Networks in the VPC. For example, an Instance attached to Private Network A will not be able to access the internet via a Public Gateway in Private Network B.
-</Message>
+- A **scope**. This shows whether teh route is advertised across the entire VPC, or (in the case of default routes), only certain Private Networks.
 
 When deciding which route to apply, the route table reads the routes from most specific to least specific, in terms of destination IP range. The first matching route encountered is the one that determines the path for the traffic. Therefore, a route to destination `172.16.8.0/22` is applied before a default route to `0.0.0.0/0`.
 
@@ -61,9 +58,8 @@ Bear in mind the following when activating VPC routing:
 
 - Once activated on a given VPC, routing cannot be deactivated on that VPC.
 - When routing is activated, all Private Networks on the VPC can communicate.
-- We do not currently offer an ACL/firewall feature to prevent communication between certain Private Networks/resources once routing is activated. However, users may choose to configure ACLs directly on certain resources (e.g. Instances, Elastic Metal servers) using tools such as `iptables` or `nftables`.
-- Public Gateways remain scoped to the Private Network to which they are attached. They do not advertise the default route on other Private Networks in the VPC. For example, an Instance attached to Private Network A will not be able to access the internet via a Public Gateway in Private Network B.
-- Custom routes are scoped to the Private Network(s) of the "next hop" resource. Their routes are not propagated to other Private Networks in the VPC. For example, in the scenario of using a custom route to route traffic towards a VPN tunnel, the origin of the packet must be in the same Private Network as the resource hosting the VPN.
+- Network ACLs, to finely control and filter traffic within a VPC, are in Public Beta and currently available via the [VPC API](/vpc/reference-content/understanding-nacls/) only. Alternatively, users may choose to configure NACLs directly on certain resources (e.g. Instances, Elastic Metal servers) using tools such as `iptables` or `nftables`.
+- The scope of route advertisements for custom routes and default routes to Public Gateways depends on when you created your VPC, and/or whether you have updated its routing behavior to the most recent version. [Read the full documentation below](TODO) for details.
 
 ## Best practices
 
@@ -77,6 +73,80 @@ We recommend that you build your VPC infrastructure with **separation of concern
 
 For example, you may use one Private Network for frontend resources and another for backend resources, limiting public access only via Load Balancers and/or Public Gateways.
 
+## Updating routing behavior
+
+From TODO DATE, new routing behavior is available for VPCs.
+
+- This routing behavior will be applied automatically to VPCs created after TODO DATE, or where routing is only activated after this date. 
+- Pre-existing VPCs must be [updated](TODO) to accept this new behavior
+
+|  | Old behavior | New behavior |
+|---|---|---|
+| Custom routes | Custom route advertisements are scoped only to the Private Network(s) to which the “next hop” resource is directly attached. | Custom route advertisements are scoped to the entire Private Network as standard. |
+| Default routes | Public Gateways' default route advertisements are scoped only to the Private Network(s) to which the gateway is attached.<br/><br/>Private Networks cannot receive default route advertisements from Public Gateways they are not directly attached to. | Standard behavior remains unchanged, but now each Private Network can opt in to receive default route advertisements from across the entire VPC. |
+
+### Custom routes
+
+Previously, custom routes were scoped only to the Private Network(s) of the “next hop” resource. Their routes were not propagated to other Private Networks in the VPC. For example, in the scenario of using a custom route to route traffic towards a VPN tunnel, the origin of the packet had be in the same Private Network as the resource hosting the VPN.
+
+With new routing behavior, custom routes are scoped to the entire VPC as standard. All Private Networks in the VPC receive route advertisements for all custom routes. This gives enhanced flexibility when using custom routes to route traffic towards VPN tunnels.
+
+You can configure [Network ACLs](/vpc/reference-content/understanding-acls) via the VPC API if you want to restrict traffic flow along custom routes. 
+
+<Message type="note">
+If you create a custom route with a destination of `0.0.0.0/0`, this custom route is treated in the same way as a **default route** advertised by a Public Gateway:
+- Its route will be advertised locally on the 'next hop' resource's Private Network.
+- Other Private Networks who have opted in to receive default routes from throughout the VPC will also receive this route.
+</Message>
+
+### Default routes
+
+Previously, Public Gateways could only advertise their default routes to the Private Networks to which they were directly attached. Resources on other Private Networks within the VPC could not access the public internet via these remote Public Gateways.
+
+With new routing behavior, this standard behavior remains unchanged. Default routes' scope is still, by default, limited to their directly attached Private Networks.
+
+However, you now have an additional option to enable each Private Network to receive advertisements of **all** default routes throughout the entire VPC. This includes routes towards all Public Gateways advertising a default route, as well as any custom-created default routes. This allows resources on other Private Networks to find access to the public internet, even if they do not have their own attached gateway.
+
+<Message type="note">
+The option to receive all default route advertisements must be enabled on a per-Private-Network basis. 
+
+This means that each Private Network in a VPC can opt to either receive **only** default routes from directly attached Public Gateways (and local custom default routes, if they exist), or **all** default routes being advertised throughout the whole VPC.
+
+If you wish to exercise more granular control over default route advertisements, we recommend that you configure [Network ACLs](/vpc/reference-content/understanding-acls) via the VPC API.
+</Message>
+
+TODO: add explanation about what happens when you're receiving multiple default route announcements?
+
+See the [documentation](TODO) on how to manage default route scope for a given Private Network, once you have [updated](TODO) to new routing behavior.
+
+### Impact on existing setup
+
+When you update to new routing behavior, the only automatic change is that your custom routes (if any) will now be advertised across the whole VPC.
+
+Your Private Networks will continue to receive only their local default route announcements, **unless** you enable `Receive all default route announcements` in each Private Network's settings. Therefore, there is no risk of the scope of default route announcements automatically changing without your specific intervention, even after updating to new routing behavior.
+
+Your existing setup may be impacted by the new behavior if you want your custom routes to be scoped only to the next-hop resource's Private Network. In this case we recommend that you use [Network ACL rules](/vpc/reference-content/understanding-acls) via the VPC API to limit access to the custom route.
+
+### Example use of NACLs to mitigate impact
+
+Imagine the following scenario:
+
+Your VPN has three Private Networks using the following CIDR blocks: 
+  - `backend-net`: `10.0.0.0/24`
+  - `frontend-net` `10.0.1.0/24`
+  - `monitoring-net`: `10.0.2.0/24`
+
+There is a custom route configured in your VPC, that routes all source traffic destined for `192.168.100.0/24` to the Instance `vpn-gateway-host` as next hop. This Instance hosts a VPN gateway, and is attached only to Private Network `monitoring-net`, with the private IP address `10.0.2.42/32`.
+
+You want to prevent resources attached to `backend-net` and `frontend-net` from sending traffic to this VPN gateway, under new routing behavior where custom routes are advertised throughout the VPC. You want only resources attached to `monitoring-net` to be able to send traffic to the VPN gateway.
+
+You could create two NACL rules to **Deny** traffic first from `10.0.0.0/24` (`backend-net`) and then from `10.0.0.1/24` (`frontend-net`) towards destination `10.0.2.42/32` (`vpn-gateway-host`). When combined with a default NACL rule to **Allow** all other traffic, this would effectively block resources on `backend-net`.
+
+Alternatively, and aligned with best practice, when the default NACL rule **Denies** all traffic not matched to a specifc rule, `backend-net` and `frontend-net` will already be blocked from sending traffic to `vpn-gateway-host` on `monitoring-net`. Since NACLs do not filter traffic between resources attached to the same Private Network, other resources on `monitoring-net` would still be able to successfully route traffic to `vpn-gateway-host`. 
+
+TODO CHECK THIS example
+-Would it be better to modify the custom route?
+
 ## Limitations
 
 - Managed Databases are not currently compatible with routing. The VPC cannot automatically route between Managed Databases on different Private Networks, or (for example) between a Managed Database on one Private Network and an Instance on a different Private Network.