Going further with the VPC Public Gateway

VPC Public Gateway - Overview

Virtual Private Cloud (VPC) provides network functionalities for your Scaleway cloud. VPC products include:

  • Private Networks, enabling you to build a virtual Layer 2 network between your instances.
  • Public Gateway, enabling IP autoconfiguration of your private networks and facilitating their communication with the Internet.

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.

Requirements

Configuring Instances

Automatic Configuration

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:

  • enable DHCP on the interfaces plugged into a private network
  • make the default route received by DHCP the primary route for all traffic on the instance
  • keep the route to the Scaleway Metadata API more specific (see below).

If your instance does not get autoconfigured, it may be that you are using an old version of the scaleway-ecosystem package. scaleway-ecosystem 0.0.4 or later is required. Use the following command to update it:

  • On Ubuntu (Focal, Bionic and Xenial) or Debian (Stretch and Buster):
# 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

Manual Configuration

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

Troubleshooting

  • Issue: I cannot connect to my instance using SSH after after attaching it to a private network which has a public gateway

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.

  • Issue: I attached the public gateway to my private network, but the services provided by the gateway are not working (DHCP, NAT, DNS etc)

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

3 . Identify the MAC address of the gateway in your private network using either the Scaleway Console or the API (mac_address field of the GatewayNetwork). We’ll use 02:00:b1:ac:ca:fe as an example.

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 fe80::000:b1ff:feac:cafe

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 ping fe80::000:b1ff:feac:cafe%priv0.

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.

Limitations

  • 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.

Other Resources

  • The VPC Public Gateway API lets you access the full range of functionality for your Public Gateways. The API Reference contains a Quickstart Guide to help you get started with creating your first Public Gateway, and comprehensive reference information for specific endpoints.
  • You can keep an eye on the VPC Changelog for information concerning future updates to the functionality and features of the VPC Public Gateway.

Discover the Cloud That Makes Sense

Get started now