Architecture

Routing within Hetzner Networks

This section assumes you are familiar with the difference between switches and routers and have a basic understanding of the layers in the OSI model.

Communication within Hetzner Networks happens via two different communication layers depending on the subnet type:

• vSwitch subnet at Layer 2 (Ethernet / Data Link Layer):

  On-link (Direct) Communication

  Source
  dedicated server

  →

  Destination
  dedicated server
  
  

  Both dedicated servers are directly connected via a switch. This allows the source to use ARP to resolve the MAC address of the destination and send packets directly to the destination without additional hops in between.

• Cloud subnet at Layer 3 (IP / Network Layer):

  Off-link (Routed) Communication

  
  

  Cloud servers only:

  Source
  cloud server

  →

  Cloud
  Gateway

  →

  Destination
  cloud server
  
  

  Cloud server and dedicated server:

  Source / Desti.
  dedicated server

  ↔

  vSwitch
  Gateway

  ↔

  Cloud
  Gateway

  ↔

  Des. / Source
  cloud server
  
  

  The servers are not directly connected. The source has to use ARP to resolve the MAC address of the gateway and send packets to the gateway. The gateway forwards the packet to the destination or the next hop towards the destination.

Example visualization

10.0.0.0/16
10.0.0.0/24
10.0.1.0/24
↕
⚯
Network
subnet
subnet of type vSwitch
directly connected
directly connected via switch

Example routes

Following shows the routes needed to reach the private IPs in the example visualization above.

On the cloud server:

On dedicated server A:

Routing through several networks

When you send packets between the Internet and the client, they pass through two networks — the private network and the public network.

As explained in the FAQ about technical details, the MTU of Hetzner cloud servers is different in private and public interfaces.

In the example above, an incoming packet with an MTU of 1500 bytes should be able to reach the cloud server router without any issues. However, if the router cannot perform IP fragmentation, it cannot forward the packet through the private interface and the packet is dropped.

You can run ip link show to check the MTUs of all interfaces on your system.

Routing from network-isolated environments

If you have a network-isolated environment on your system (e.g. Docker container or LXC), it will usually have its own interface settings.

In the example below, the network-isolated environment and the underlying host can exchange packets with an MTU of 1500 bytes:

If the network-isolated environment uses the underlying host as a router, the host from the example above will forward the packet via the private interface with an MTU of 1450 bytes.

If the network-isolated environment sends a packet with an MTU of 1500 bytes, it should be able to reach the underlying host without any issues. However, if the host cannot perform IP fragmentation, it cannot forward the packet through the private interface and the packet is dropped.

Configuring multi-network routes

If routing is implemented correctly, the setup should look similar to this:

Before configuring routes in a NAT/client setup as visualized above, it is important to understand how packets are expected to move through the network.

Example:

A private client with the private IP 10.0.0.3 sends a request to the public IP 203.0.13.1.

On the Cloud side, traffic is configured to be routed via the NAT server (private IP 10.0.0.2, public IP 198.51.9.1). The client servers can reach the NAT server via the private network gateway.

Request to public target:

• The client server must have a static route that sends traffic destined for IPs outside its own network (e.g., public IPs such as 203.0.13.1 or private IPs such as 192.168.0.3) to the private network gateway, in this example 10.0.0.1.

  # default route for public IPs
  ip route add default via 10.0.0.1
  
  # static route for traffic to a private network outside the server's own subnet
  ip route add 192.168.0.0/16 via 10.0.0.1

• The private network must have a route that sends traffic destined for IPs outside its own network (e.g., public IPs such as 203.0.13.1 or private IPs such as 192.168.0.3) to the private IP of the NAT server, in this example 10.0.0.2. You can use the Hetzner Console or the Hetzner API.

  Default route for public IPs

  • Destination: 0.0.0.0/0
  • Gateway: private IP of the NAT server

  Route for traffic to a private network outside the own subnet

  • Destination: 192.168.0.0/16
  • Gateway: private IP of the NAT server

Finally, the NAT server must be configured to forward the traffic so the request can be sent out to the target.

Response to private client:

You don't need to configure any extra routes. For the response traffic, the NAT server only needs a route that directs packets to private IPs such as 10.0.0.3 via the private network gateway 10.0.0.1. Servers in a private network have this route automatically.