diff --git a/menu/navigation.json b/menu/navigation.json index 02942308e9..8e33995463 100644 --- a/menu/navigation.json +++ b/menu/navigation.json @@ -3211,6 +3211,10 @@ { "label": "I can't delete my VPC or Private Network", "slug": "cant-delete-vpc-pn" + }, + { + "label": "I am experiencing connectivity or routing issues", + "slug": "vpc-pn-routing-connectivity-issues" } ], "label": "Troubleshooting", diff --git a/pages/ipam/reference-content/public-connectivity-best-practices.mdx b/pages/ipam/reference-content/public-connectivity-best-practices.mdx index b15bffe9e3..61b1ce81c4 100644 --- a/pages/ipam/reference-content/public-connectivity-best-practices.mdx +++ b/pages/ipam/reference-content/public-connectivity-best-practices.mdx @@ -49,7 +49,7 @@ In the future, look out for even more improvements to our flexible IP offering, We strongly recommend that you disable public connectivity on all of your Scaleway resources, unless it is absolutely required. Attaching resources to Private Networks, and limiting their communication to these networks brings the following advantages: - **Minimized attack surface**: Without a public IP address, the resource is not exposed directly to the internet, decreasing the risk of DDoS or brute force attacks, or unauthorized access. -- **Reduced cost**: Public (flexible) IP addresses are [billed](https://www.scaleway.com/en/pricing/), whereas Private Networks and the private IP addresses that attach resources to Private Networks are free of charge (except for Elastic Metal servers). +- **Reduced cost**: Public (flexible) IP addresses are [billed](https://www.scaleway.com/en/pricing/), whereas Private Networks and the private IP addresses that attach resources to Private Networks are free of charge (except for Elastic Metal servers and Apple silicon). - **Improved latency**: Communication between resources over a Private Network is generally faster, as it does not need to be routed through the public internet. Depending on the resource type, public connectivity can be disabled by: diff --git a/pages/vpc/troubleshooting/vpc-pn-routing-connectivity-issues.mdx b/pages/vpc/troubleshooting/vpc-pn-routing-connectivity-issues.mdx new file mode 100644 index 0000000000..c7e1e2a7ad --- /dev/null +++ b/pages/vpc/troubleshooting/vpc-pn-routing-connectivity-issues.mdx @@ -0,0 +1,61 @@ +--- +meta: + title: I am experiencing connectivity or routing issues with my VPC or Private Network + description: Troubleshoot access and connectivity issues with your Scaleway VPC or Private Network. Learn how to resolve common problems and get your network up and running smoothly. +content: + h1: I am experiencing connectivity or routing issues with my VPC or Private Network + paragraph: Troubleshoot access and connectivity issues with your Scaleway VPC or Private Network. Learn how to resolve common problems and get your network up and running smoothly. +tags: vpc private-network access connectivity ssh ip +dates: + validation: 2025-02-21 + posted: 2025-02-21 +categories: + - network +--- + +You may have problems with connectivity between resources in a VPC or Private Network, or issues with routing packets. + +This page helps you solve potential errors that are related to VPC connectivity and routing. + +## My Managed Database cannot communicate with other resources in my VPC + +This is normal, as VPC routing is not yet supported by Managed Databases for PostgreSQL or Managed Databases for Redis. Adding support for Managed Databases is planned for the future. + +## I cannot deactivate routing on my VPC + +This is standard behavior: + +- Once you have activated routing on a VPC, you cannot deactivate it +- You do not have the option to create a new VPC where routing is deactivated + +## I cannot route between VPCs/Private Networks in different regions, or different Scaleway Projects. + +Currently, routing is only supported between Private Networks in a single VPC. We do not support: + +- Routing between two different VPCs +- Routing between Private Networks in different Scaleway Projects, or different regions + +Watch out for our VPC Peering solution, planned for the future, which will enable communication between different VPCs. + +## I am experiencing issues with Elastic Metal server connectivity to a Private Network + +Note that some manual configuration of the network interface is required when attaching Elastic Metal servers to Private Networks. Follow the steps in our [dedicated documentation](/elastic-metal/how-to/use-private-networks/#how-to-configure-the-network-interface-on-your-elastic-metal-server-for-private-networks). + +## I am experiencing issues with VM (hosted on Elastic Metal server) connectivity to a Private Network + +Ensure you have correctly attached the VM to the Private Network by specifying the MAC address, and carried out the necessary configuration of the network interface for your VM, e.g. [via the Proxmox interface](/tutorials/setup-elastic-metal-proxmox-cluster-with-private-networks/#configuring-the-private-network). + + +Using the same MAC address on VMs in different AZs, or switching such MAC addresses between AZs, is not compatible with VPC routing. Ensure each VM has a unique MAC address. + + +## My resources cannot communicate via their hostnames + +See our dedicated documentation on [resolving private DNS errors](/vpc/troubleshooting/private-dns-dhcp-not-working/). + +## I am experiencing other connectivity issues + +Check the [Scaleway Status page](https://status.scaleway.com/), to see whether there are any ongoing incidents which could affect the connectivity or network access of your resources. + + +