> For the complete documentation index, see [llms.txt](https://docs.glesys.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.glesys.com/products/compute/vmware-virtual-machines/how-tos/manage-private-networks/routable-segments.md).

# Routable segments

Segments within a private network can be changed from isolated to routable. When a segment is in routable mode, it can talk to other routable segments, even if they are in different data centers.

***

To learn how to set up a private network, including creating segments, connecting adapters, and configuring the operating system, see [Manage private networks](/products/compute/vmware-virtual-machines/how-tos/manage-private-networks.md).

## Example setup

In this example, we already have two isolated segments: one in Falkenberg (lab1) with the address range 192.168.0.0/24 and one in Stockholm (lab2) with the address range 192.168.1.0/24.

Each segment has four VMs, each with a different OS (Alma Linux, Debian, Ubuntu, and Windows Server) for demonstration purposes.

<figure><img src="https://3379166260-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FlMZhhdQNcWOpX5Bj48GK%2Fuploads%2FR2WdEB60aQQ6AySb8Cuk%2Froutable-segments2.png?alt=media&amp;token=ca8e0fd2-04a9-4d56-8131-47ad2666e8d8" alt=""><figcaption></figcaption></figure>

## Change a segment to routable in the control panel

To change a segment to routable mode, first select the private network in question, then click the three dots next to the segment and select **Edit**.

<figure><img src="https://3379166260-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FlMZhhdQNcWOpX5Bj48GK%2Fuploads%2Fwxwr2VCWfWUA7nahEN8S%2Fmake-segment-routable-01.png?alt=media&amp;token=80433209-f0a8-4dd8-9217-e493f88a7e3a" alt=""><figcaption></figcaption></figure>

Select **Routable** and click **Save**.

<figure><img src="https://3379166260-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FlMZhhdQNcWOpX5Bj48GK%2Fuploads%2FKqzU84LZgPJ4PIJudt2P%2Fmake-segment-routable-02.png?alt=media&amp;token=9824face-5ab0-4f37-a693-959111b9d6af" alt=""><figcaption></figcaption></figure>

Repeat these steps for all the segments that should be able to communicate with each other.

## Add static routes in the VM's operating system

Now that the segments are routable, a gateway is added to them automatically. Continuing with the example, the setup will now look like the image below.

<figure><img src="https://3379166260-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FlMZhhdQNcWOpX5Bj48GK%2Fuploads%2F9z936ty5v4q67ec0enFH%2Froutable-segments1.png?alt=media&amp;token=a389c0e5-60c3-47eb-a209-f76c9e060e3c" alt=""><figcaption></figcaption></figure>

The next step to establish communication between the VMs in different segments is to create static routes to the other segments. In this example, we have two segments: *lab1* with the IP range 192.168.0.0/24 and *lab2* with the IP range 192.168.1.0/24.

In each segment, the first IP address is the gateway. For example, in the network 192.168.0.0/24, the gateway is 192.168.0.1.

In the *lab1* segment, traffic going to 192.168.1.0/24 will be routed through the gateway at 192.168.0.1.&#x20;

In the *lab2* segment, traffic going to 192.168.0.0/24 will be routed through the gateway at 192.168.1.1.

The examples below show how to add a static route from the *lab1* segment to 192.168.1.0/24 through the gateway at 192.168.0.1. To set up a static route from the *lab2* segment, do the opposite (route 192.168.0.0/24 through the gateway at 192.168.1.1). You have to set up routes in both directions, or the traffic can't flow correctly. In the examples below, we assume that the network interface for the private network is *ens224* in Linux and *Network 2* in Windows.

{% tabs %}
{% tab title="Debian 13" %}
Network configuration in Debian 13 at Glesys is done in the file `/etc/network/interfaces.d/50-cloud-init`. Leave the current configuration as it is, but add the two lines (`post-up` and `pre-down`) to the interface *ens224,* like the example below.

{% code title="Part of /etc/network/interfaces.d/50-cloud-init" %}

```
auto ens224
iface ens224 inet static
    address 192.168.0.6/24
    post-up route add -net 192.168.1.0 netmask 255.255.255.0 gw 192.168.0.1
    pre-down route del -net 192.168.1.0 netmask 255.255.255.0 gw 192.168.0.1
```

{% endcode %}

Once the static routes are added to the file, restart the network using:

{% code title="Command" %}

```
sudo systemctl restart networking
```

{% endcode %}

Let's verify the routing table. If everything is set up correctly, there should be a line saying `192.168.1.0/24 via 192.168.0.1`.

<pre data-title="Command and output. Command is highlighted."><code><strong>ip route
</strong>default via 203.0.113.1 dev ens192 proto static metric 100
203.0.113.0/24 dev ens192 proto kernel scope link src 203.0.113.159 metric 100
192.168.0.0/24 dev ens224 proto kernel scope link src 192.168.0.6 metric 101
192.168.1.0/24 via 192.168.0.1 dev ens224 proto static metric 101
</code></pre>

{% endtab %}

{% tab title="Ubuntun 26.04" %}
In Ubuntu, the network configuration is done in the file `/etc/netplan/50-cloud-init.yaml`.

At the end of the file, below the existing configuration, add the static routes to the *ens224* network interface.

{% code title="Part of /etc/netplan/50-cloud-init.yaml" %}

```
    ens224:
      addresses:
        - "192.168.0.7/24"
      routes:
        - to: "192.168.1.0/24"
          via: 192.168.0.1
```

{% endcode %}

Apply the new configuration with `sudo netplan try`. The `try` command will automatically revert any changes unless you confirm, preventing the VM from losing its internet connectivity. Press <kbd>Enter</kbd> to confirm when you see the message *Do you want to keep these settings?*

<pre data-title="Commands and output. Commands are highlighted."><code><strong>sudo netplan try
</strong>Do you want to keep these settings?


Press ENTER before the timeout to accept the new configuration


Changes will revert in 112 seconds
Configuration accepted.
</code></pre>

Let's verify the routing table. If everything is set up correctly, there should be a line saying `192.168.1.0/24 via 192.168.0.1`.

<pre data-title="Command and output. Command is highlighted."><code><strong>ip route
</strong>default via 203.0.113.1 dev ens192 proto static metric 100
203.0.113.0/24 dev ens192 proto kernel scope link src 203.0.113.166 metric 100
192.168.0.0/24 dev ens224 proto kernel scope link src 192.168.0.7 metric 101
192.168.1.0/24 via 192.168.0.1 dev ens224 proto static metric 101
</code></pre>

{% endtab %}

{% tab title="Alma Linux 10" %}
In AlmaLinux, network configuration is done with NetworkManager and the command `nmcli`.

First, you'll have to figure out the name of the connection that uses the *ens224* interface card.

<pre data-title="Command and output. Commands are highlighted."><code><strong>sudo nmcli connection
</strong>NAME                UUID                                  TYPE      DEVICE
cloud-init ens192   dfaf916e-1ddf-5437-bf6d-d2dbb171f650  ethernet  ens192
Wired connection 1  b523dc12-b7c9-3c21-b7ec-1d941516262e  ethernet  ens224
lo                  acc56767-cbcf-49d7-82c3-0f3e4527bda8  loopback  lo
</code></pre>

In this case, the connection is called *Wired connection 1*.

If the connection isn't already configured, start by assigning it an IP address and setting it to static mode (skip this step if the connection already has an IP address).

{% code title="Commands" %}

```
sudo nmcli connection modify "Wired connection 1" ipv4.address "192.168.0.5/24"
sudo nmcli connection modify "Wired connection 1" ipv4.method manual
```

{% endcode %}

Create the static route to the other segment and bring up the connection:

{% code title="Commands" %}

```
sudo nmcli connection modify "Wired connection 1" +ipv4.routes "192.168.1.0/24 192.168.0.1"
sudo nmcli connection up "Wired connection 1"
```

{% endcode %}

Let's verify the routing table. If everything is set up correctly, there should be a line saying `192.168.1.0/24 via 192.168.0.1`.

<pre data-title="Command and output. Command is highlighted."><code><strong>ip route
</strong>default via 203.0.113.1 dev ens192 proto static metric 100
203.0.113.0/24 dev ens192 proto kernel scope link src 203.0.113.76 metric 100
192.168.0.0/24 dev ens224 proto kernel scope link src 192.168.0.5 metric 101
192.168.1.0/24 via 192.168.0.1 dev ens224 proto static metric 101
</code></pre>

{% endtab %}

{% tab title="Windows Server 2025" %}
We assume that the network interface (*Network 2*) in the operating system is already configured with an IP address (in this example, 192.168.0.8 with a netmask of 255.255.255.0).

To add a static route, open the Terminal. Click on the **Start menu** and select **Terminal**, or search for Terminal if it doesn't show.

<figure><img src="https://3379166260-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FlMZhhdQNcWOpX5Bj48GK%2Fuploads%2FAk4vL17r5TPhKAqIeJ06%2Fwindows-terminal.png?alt=media&amp;token=8352a478-1a50-4659-83c6-7535f4de7ee7" alt=""><figcaption></figcaption></figure>

In the Terminal, execute the following command (the `-p` flag makes the route persistent across reboots):

<pre data-title="Command and output. Command is highlighted."><code><strong>route -p add 192.168.1.0 mask 255.255.255.0 192.168.0.1
</strong> OK!
</code></pre>

Let's verify the routing table. There's a lot of output, so you might need to scroll up a bit to find the lines shown here. Look for *Persistent Routes*. The output in the example below has been cut to the relevant parts. If you see the network address 192.168.1.0 with a gateway address of 192.168.0.1, everything is set up correctly.

<pre data-title="Command and sample output. Command is highlighted."><code><strong>route print
</strong>...
Persistent Routes:
  Network Address          Netmask  Gateway Address  Metric
          0.0.0.0          0.0.0.0      37.152.57.1  Default
      192.168.1.0    255.255.255.0      192.168.0.1       1
...
</code></pre>

{% endtab %}
{% endtabs %}

## Verify the connectivity

To verify connectivity, ping a VM in the other segment (in this example, a VM in the segment named *lab2*).

<pre data-title="Command and output. Command is highlighted."><code><strong>ping 192.168.1.5
</strong>PING 192.168.1.5 (192.168.1.5) 56(84) bytes of data.
64 bytes from 192.168.1.5: icmp_seq=1 ttl=58 time=9.91 ms
64 bytes from 192.168.1.5: icmp_seq=2 ttl=58 time=9.73 ms
64 bytes from 192.168.1.5: icmp_seq=3 ttl=58 time=10.3 ms
64 bytes from 192.168.1.5: icmp_seq=4 ttl=58 time=9.89 ms
<strong>^C
</strong>--- 192.168.1.5 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3002ms
rtt min/avg/max/mdev = 9.727/9.949/10.268/0.197 ms
</code></pre>