Tech insights and news. Best served hot.



Segmentation with Multiple Private Networks

Not every server should be directly accessible from the Internet. This is why our customers often make use of the possibility of strategically positioning servers in a private network and protecting them behind a firewall, a load balancer or a VPN. Now you can define multiple separate private networks, which allows you to build more complex setups tailored to your specific requirements.

Sample applications with multiple private networks

Private networks are used, for example, if web workers, but not their database backends, should be accessible directly from the Internet. They are also employed to protect servers in the cloud behind a firewall such as OPNsense. With the support of multiple private networks, you can now also combine these proven concepts, with a firewall/load balancer setup acting as the interface to the Internet and forwarding legitimate requests to the web workers via the first private network. These web workers in turn access the database backends via a second, separate private network to ensure proper isolation of the individual security zones.

Sample application 1

In addition to your public web application, you may want to run internal services in the cloud, while protecting them from access from less trusted zones. Separate private networks can be used to implement this scenario as well. Traffic for your web application is routed by the firewall via one private network to your web server, while your internal tools are connected to your VPN endpoint via a separate private network. This way, your public and internal servers are safely separated in two independent private networks.

Sample application 2

How to set up private networks

The new API endpoint networks acts as the key interface for your private networks. With the request:

$ curl -i -H "$AUTH_HEADER"

you are given an overview of your existing private networks:

HTTP/1.0 200 OK
Content-Type: application/json

    "href": "",
    "created_at": "2019-05-29T13:18:42.511407Z",
    "uuid": "2db69ba3-1864-4608-853a-0771b6885a3a",
    "name": "my-network-name",
    "mtu": 9000,
    "subnets": [
        "href": "",
        "uuid": "33333333-1864-4608-853a-0771b6885a3a",
        "cidr": ""
    "tags": {}

With a POST request to the endpoint networks, you can easily create additional private networks. The only mandatory parameter you need to provide is a name so you can recognize the network later. Using the existing API endpoint servers you can now determine whether and in which private networks a server should have interfaces. This works at the time you create a new server as well as later on.

By default, our system assigns a randomly selected private IPv4 range ("subnet") to the new network and will later assign IP addresses from this range to your servers in this network through DHCP. It goes without saying that you can deactivate both of these if desired. And as before, you can statically configure any IPv4 and IPv6 addresses on servers in your private networks. In the case of a network with a subnet, you simply need to make sure you avoid address conflicts with our DHCP servers. More information about the available options can be found in our API documentation.

Some useful hints

For optimal performance in the private network, the MTU is 9000 bytes ("jumbo frames") by default. You can, of course, change the MTU at any time, e.g. if your specific setup requires the 1500 bytes known from the classic Ethernet.

Please note that a server must be assigned an IPv4 address via our DHCP server in at least one of its networks. The reason for this is that DHCP is also used to set the required route so that cloud-init on your server can reach our metadata server.

In the near future we will also be expanding our cloud control panel so you can directly select existing or new private networks when creating a new server via your browser.

Last but not least, you can set user-defined tags for your private networks and filter for them.


In many cases, a more granular segmentation of the servers used can make sense, either to reflect the logical structure of your setup, or to add another level to your security concept. The latest evolution of our private networks makes it possible for you to build up your server landscape in the way that best suits you and your specific use case.

Connected at all levels,
Your team

More news. Further insights.

Try it yourself and launch a Swiss Linux server today!