Virtual Private Cloud (VPC) provides network functionalities for your Scaleway cloud. VPC products include:
This tutorial follows on from Getting started with the VPC Public Gateway to give you more advanced information about troubleshooting and manual configuration. For information about the core concepts behind the VPC Public Gateway, and instructions for creating and configuring a gateway through the Scaleway console, please refer to that first tutorial.
Default instance images for Ubuntu, Debian and CentOS support autoconfiguration of interfaces plugged into a Private Network attached to a Public Gateway.
They leverage helper scripts provided by the
scaleway-ecosystem package. These scripts:
If your instance does not get autoconfigured, it may be that you are using an old version of the
scaleway-ecosystem 0.0.4 or later is required. Use the following command to update it:
# apt update && apt install scaleway-ecosystem # apt list scaleway-ecosystem Listing... Done scaleway-ecosystem/bionic,now 0.0.4-2 all [installed]
# rpm -vUh https://github.com/scaleway/scaleway-packages/releases/download/v0.0.4/scaleway-ecosystem-0.0.4-1.noarch.rpm
If you cannot or do not want to rely on the automatic configuration mechanism, you can configure your instance manually.
Note: if your instance supports autoconfiguration and you want to configure manually, make sure to disable autoconfiguration as follows:
# mv /lib/udev/rules.d/72-scw-vpc-iface.rules /lib/udev/rules.d/.72-scw-vpc-iface.rules # reboot
By default, instances are configured with a default route on their public interface that allows them to reach the Scaleway Metadata API. When an instance is autoconfigured using DHCP and learns its default route through the gateway, it ends up with two default routes: one towards the gateway on the private network and the other towards the Scaleway Metadata API on the public interface. It is necessary to adjust the metric of the default route through the gateway to make it the preferred one and to configure the route to the Scaleway Metadata API manually.
1 . Update the route to the Scaleway Metadata API.
The endpoint for the Scaleway Metadata API is
169.254.42.42/32 and the gateway depends on your instance. You can retrieve it with the following command:
# ip route show default via 10.68.2.114 dev eth0 proto dhcp metric 100 10.68.2.114/31 dev eth0 proto kernel scope link src 10.68.2.115 metric 100
The address of the gateway to the Scaleway Metadata API is
10.68.2.114. Now, add a specific route to the API as follows:
# ip route add 169.254.42.42/32 via 10.68.2.114
2 . Configure DHCP on the instance, adjusting the metric of the default route.
Example using netplan:
network: version: 2 ethernets: ens4: dhcp4: true dhcp4-overrides: route-metric: 50
and using ifupdown:
auto ens4 iface ens4 inet dhcp metric 50
Is DHCP enabled on your Public Gateway, and is it set to advertise a default route (true by default)?
If not, disconnect the instance from the private network, as there may be other factors impacting your instance, like one of your instances running a DHCP server
If so, this is expected behavior as all the traffic towards your instance now goes through the Public Gateway. To access your instance using SSH, first create a static NAT association between a port of your public gateway (eg 2222) and the private IP assigned to your instance, on the SSH port (22 by default). Then, SSH to the public gateway’s IP on port 2222.
First, check whether the gateway is properly plugged into the private network. We currently have a known issue where the GatewayNetwork gets created successfully without the gateway actually getting plugged into the network. To check whether this is the issue you are experiencing, please do the following:
1 . In an instance plugged into the private network, identify the private network’s network interface. We’ll use
priv0 as an example.
2 . Set it as
UP to be able to use it:
ip link set priv0 up
4 . Go here, and paste the MAC address to get the IPv6 Link-Local Address of your gateway. In our example, using priv0, it is
5 . From your instance, ping the gateway on its IPv6 link-local address, taking care to specify the private network interface. In our example, using
priv0, the command is
If the address does not ping, then you are indeed experiencing this known issue. The best way to fix it is either to delete and recreate the GatewayNetwork (you can keep the same DHCP configuration by specifying a
dhcp_id upon creation), or attach a dummy private network to the gateway.
If the address does ping, then you may be either experiencing another issue, where the interface gets misconfigured, or just have an error in your configuration. To test for this, update any property of your GatewayNetwork or the associated DHCP configuration in order to trigger a reconfiguration. If this does not fix it, please check your configuration.
If the problem persists, please do not hesitate to contact us on the #vpc-public-gateway channel on the Scaleway Community Slack.
The Public Gateway currently supports only IPv4.
IPv6 support will be coming soon.
Modifying a DHCP subnet requires a renew on the client side.
Leases are not automatically renewed on the client side when changing the DHCP subnet on the Public Gateway. You have to request a renew on the client side to obtain a new lease in the new subnet.
CentOS autoconfiguration does not work with multiple Private Networks.
When a CentOS instance is attached to multiple Private Networks, which are themselves attached to a Public Gateway, routing metric priorities will not be enforced across reboot. You will have to disable routes autoconfiguration and configure them by yourself as explained in the Configuring Instances section.
In some cases, local DNS fails on autoconfigured instances.
This is due to a conflict between the Public Gateway and the API metadata DNS servers. This behavior depends on both your distribution and timing at boot time. There is currently no easy workaround for this issue.