Routing

When you create a virtual machine (VM) in Yandex Cloud, it receives a set of parameters for configuring its network environment from the virtual network. The virtual network transmits the values of these parameters to the VM using DHCP. The required network environment parameters for VMs include:

• Internal IP addresses for each network interface of the VM.
• Subnet mask: Defines the size of the subnet the VM network interface connects to.
• Host name and FQDN of the VM.
• Default gateway: The first IP address on the subnet to which the VM network interface is connected. It will receive all outbound traffic from the VM to the outside world.

VM route tableVM route table

In Yandex Cloud, VM instances are typically created with a single network interface. When being created, a VM will have a route table with only one route: the one to the default gateway with the 0.0.0.0/0 prefix. For this route (prefix), the gateway is always the first IP address on the subnet to which the VM network interface is connected.

Let's assume a VM network interface is connected to a subnet with the 192.168.10.0/24 prefix. When the VM was created, its network interface was assigned the 192.168.10.5 IP address in this subnet. The route table for the VM will appear as follows:

ip route
default via 192.168.10.1 dev eth0 proto dhcp src 192.168.10.5 metric 100

This means that all traffic bound for the virtual network must go through the 192.168.10.1 gateway (eth0 interface).

If using a VM with multiple network interfaces, keep in mind that the virtual network will configure a different default gateway for each network interface. To prevent routing conflicts, leave only one default gateway by using the ip route del command to delete the route table entries associated with other gateways.

If you create a VM with multiple network interfaces, the route table within the VM will only allow you to select the network interface for outgoing traffic based on specific destination IP prefixes.

VPC route tablesVPC route tables

VM route tables do not support forwarding traffic directly from one VM within a subnet to another. In all cases, traffic is directed to the virtual network's default gateway.

If you need granular routing at the virtual network level, use VPC route tables. This Yandex Cloud tool can be useful when processing network traffic on specialized VM instances, such as firewalls, NGFWs, secure gateways, and VPNs.

VPC route tables enable you to manage IPv4 traffic routing for VM instances. Virtual Private Cloud does not currently support IPv6.

VPC route tables are created within cloud networks and can be applied to any subnet on the same network. You cannot apply a route table to subnets belonging to a different cloud network.

A VPC route table can include one or multiple entries. Each entry defines a static route within the virtual network.

Static routesStatic routes

Each VPC route table entry must include:

• Destination prefix: Prefix of the destination IPv4 route in CIDR notation, e.g., 10.20.30.0/24.
• Next hop: Type of the gateway that will handle outgoing traffic for the specified destination prefix. Allowed values include:
  • IP address: IP address of the destination gateway, e.g., the internal IP of a VM within one of the subnets.
  • Gateway, to send traffic through a NAT gateway. For this gateway type, specify the name of an already existing NAT gateway on the cloud network.

If you create multiple entries with overlapping prefixes, the prefix with the larger subnet mask will have higher priority. For example, between two entries with the 172.16.0.0/20 and 172.16.0.0/24 destination prefixes, the entry with the 172.16.0.0/24 prefix will be used for sending traffic, as it has higher priority.

When creating a static route with an IP address as the next hop, you can specify an internal IP address previously unused in this cloud network. In this case, the virtual network will discard all traffic to the destination prefix of the route until you run a VM with that IP address.

Static routes can use the default route prefix: 0.0.0.0/0. This means that all traffic not directed through more specific routes will be sent through the gateway IP address specified for this prefix.

When creating a static route with a Gateway as next hop, you can specify only the 0.0.0.0/0 default route prefix in the Destination prefix. This next hop type does not support other prefixes.

Route priority in complex scenariosRoute priority in complex scenarios

In complex routing scenarios with multiple default routes in the VPC network (subnets), outgoing traffic will follow this routing order:

• Priority 1: If you set up the default static route of 0.0.0.0/0, it will have the highest priority.

• Priority 2: If a VM has a public IP address configured and there is no default static route (priority 1) in the subnet, traffic will be routed through that public IP address.

• Priority 3: If you set up the default static route of 0.0.0.0/0 through a NAT gateway, it will have a lower priority than priorities 1 and 2.

• Priority 4: If you announce a default route of 0.0.0.0/0 using Cloud Interconnect, it will be treated as having a lower priority than routes with priorities 1, 2, and 3.

LimitationsLimitations

1. A VPC route table can only have one entry per destination prefix. Duplicating destination prefixes within the same VPC route table is not allowed. This also applies to the 0.0.0.0/0 default route prefix.

2. A virtual machine can access the internet and you can access the VM via a public IP address only if there is no 0.0.0.0/0 default static route in its subnet. If a virtual machine is behind a NAT instance, you can connect to it via an internal IP address, using the NAT instance as a jump host:

   ssh -J <NAT_instance_username>@<NAT_instance_public_IP_address> \
     <VM_user_name>@<VM_internal_IP_address>
   

3. VPC route tables cannot use link-local IP address prefixes, such as 169.254.0.0/16 and more specific ones, as they are reserved for Virtual Private Cloud internal use.

4. You cannot use the IP address of a load balancer's traffic listener as next hop.

5. When using VPC route tables to route reverse traffic from target resources of an internal load balancer, consider the traffic routing specifics.

6. You cannot use IP addresses of an application-level load balancer's traffic listener as next hop.

7. A Yandex Cloud virtual network does not allow transmitting traffic through itself. In other words, only private IP address ranges in Virtual Private Cloud can be used as destination prefixes and gateways for static routes in VPC route tables. Traffic to public destination prefixes or gateways with public IP addresses in the VPC route table will be discarded.

8. To learn more about the quota-related restrictions on the use of route tables and static routes, see Quotas and limits in the Virtual Private Cloud documentation.

Static route use casesStatic route use cases

1. Creating and setting up a NAT gateway.
2. Routing through a NAT instance.
3. Creating an IPSec VPN tunnel.
4. Creating and configuring a UserGate gateway in firewall mode.
5. Implementing a secure high-availability network infrastructure with a dedicated DMZ based on the next-generation firewall.
6. Configuring Cloud Interconnect access to cloud networks behind NGFWs.