When connecting a system to an Exoscale setup, you have multiple options. This handbook provides an overview of these options. The fundamental goal is to connect an on-premises system to an Exoscale setup, two Exoscale regions with each other, or Exoscale to a different cloud provider.

Note

It is recommended that you review the Internet Basics Handbook before this!

Understanding Private Networks

For almost every connectivity solution, you will want to create one or more private networks on Exoscale and connect your machines. Because you can assign any IP address you wish within a private network, Exoscale will not control it. This enables you to route your on-premises IP ranges into an Exoscale private network and give your Exoscale instances an IP address from your office IP range, or an IP range that you manage.

However, it is essential to note that even though Exoscale does not control the IP addresses you assign in a private network, the MAC addresses are controlled. Each instance can ONLY send packets on a private network with the MAC address assigned to it by Exoscale. Therefore, network bridging or layer-2 VPNs are impossible or must use techniques like proxy ARP.

Note

that it is possible to provision managed private networks on Exoscale that automatically assign IP addresses, but these are usually not employed when creating connectivity to other systems.

Understanding Public Networks

In contrast to private networks, public networks behave much differently on Exoscale. On the default public interface (eth0) each instance receives a public IPv4 address, and optionally also an IPv6 address. Additional IP addresses can be added by employing unmanaged (v1) Elastic IP addresses. (See Elastic IPs below.)

Other than the assigned IP addresses, no IPs can be used on the public network, and all attempts to send packets with different IPs will be blocked.

Also, all traffic from and to a public IP is subject to firewalling with security groups. For more details on this filtering, see the security groups section below.

Understanding Security Groups

Each instance on Exoscale belongs to at least one security group. Security groups act as a method of applying firewall rules to an instance. The rules can be either ingress (inbound to the instance) or egress (outbound).

If no ingress rules are defined, the default behavior is to block any inbound traffic. In contrast, egress’s default behavior is to allow all traffic unless at least one rule is defined.

It is also important to note that, just because two instances are in the same security group, it does not automatically allow traffic between these instances.

The rules can be of two types: they either filter based on the IP address of the other party, or, if the other party is an instance in the same Exoscale account, it can also be based on a security group that the other instance belongs to. This allows for creating flexible setups where, for example, all application servers can connect all database servers, regardless of which IP they receive.

Understanding Elastic IPs

On Exoscale, each instance receives a public IP, but additional IPs can be added as elastic IPs. These elastic IPs come in two flavors: managed and unmanaged.

Unmanaged Elastic IPs

Unmanaged elastic IPs can be attached to multiple instances in the Exoscale console, but can only be active on a single instance.

Facilitating the elastic IP assignment, each instance must add the elastic IP as an additional IP address to the first network interface on the instance. However, no extra routing, such as default gateway, should be added for the elastic IP address.

For details on configuring unmanaged elastic IPs, see the official documentation.

Managed Elastic IPs

Managed elastic IPs act differently to unmanaged elastic IPs. Managed elastic IPs work like basic load balancers and must be configured individually.

First of all, a managed elastic IP does not need to be added to the instance itself. Instead, a health check is configured to verify that a connection can be established to the instances attached to the elastic IP on a specific port or make a web request to the instance. It then directs all traffic that arrives on the elastic IP to one of the marked instances as healthy. By that simple load balancing is possible.

Connecting External System

Connecting an external system to Exoscale is done in one of three ways:

  • VPN
  • SD-WAN
  • MPLS

VPN

VPNs are an industry-standard solution of creating a transparent tunnel between an Exoscale private network and an external system. These VPNs are typically deployed in an own instance on Exoscale, which is responsible for terminating the encryption and sending the packets into the private network.

SD-WAN

SD-WAN-solutions add on top of the VPN concept by adding mesh routing between multiple endpoints and bypass faulty networks by rerouting packets through different connections.

MPLS

Finally, while VPNs and SD-WAN are sent over the Internet, MPLS is routed across the physical connections that also serve the Internet, but provide added benefits like guaranteed bandwidth and guaranteed latencies. It also does not require an Exoscale instance to be operated. On the downside establishing MPLS connections is usually a complex process and is on the costly side.

Building a VPN

In a typical setup, all network traffic on Exoscale goes through the public network. The traffic towards the Internet or different Exoscale zones goes through the Exoscale router.

Connecting an On-Premises System via a VPN

The solution for connecting an on-premises system to an Exoscale private network is often a VPN. The on-premises side of this system often looks like this:

Since the router and the VPN gateway are the same devices, the configuration is rather simple. The on-premises servers do not need any additional configuration.

The Exoscale side, however, is a bit different. The VPN gateway is deployed in an Exoscale instance, which is different from the router. The other instances do not have the information to send traffic via the VPN gateway. Therefore, each instance needs to have its routing table adjusted to send traffic bound for the on-premises system via the VPN gateway.

It is important to note that each instance needs to have its routing table adjusted to send traffic via the VPN.

Full VPN via On-Premises System

However, let’s say you want to deploy a VPN where all your machines send internet traffic through your on-premises setup.

Typically Instance A (on the left) sends all traffic to the Internet using its public IP address using the Exoscale router. If you want to use the VPN and route traffic through an on-premises system, you need to adjust the routing table of Instance A to send all traffic via Instance B (in the middle). Instance B encrypts the traffic and sends it to the on-premises VPN gateway. The on-premises VPN gateway decides where to send the traffic to the Internet, or an on-premises server.

VPN Types

Exoscale has ready-made images for many commercial VPN solutions. Details can be found on the Exoscale Marketplace.

IPsec

IPsec is a network traffic encryption standard used by many under various VPN types. IPsec itself is technically not a VPN, and it can be used when building a site-to-site VPN. However, it is not usable as a VPN for mobile workstations as it needs fixed IP addresses on both ends to work.

PPTP

PPTP is a legacy VPN type based on the Point To Point Protocol (PPP). Using PPP is no longer a good idea because it does not support adequate encryption. Authentication is done using username and password only.

L2TP

L2TP is a VPN included by default in Windows. It uses IPsec for encryption and is suitable for mobile workstations without fixed IP addresses as long as the VPN’s server-side has a fixed IP. Authentication can be done using a shared key, certificate, or username and password.

OpenVPN

OpenVPN is an open-source VPN solution that can do various VPN setups, including layer-2 (ethernet) or layer-3 (routed) VPN. A multitude of authentication methods is also available. OpenVPN enables the usage from mobile workstations.

Cisco ASA

An often on-premises used application is Cisco ASA; it is Cisco’s proprietary SSL VPN solution. It can be deployed on Exoscale as an instance. For details see the Exoscale Marketplace.

SoftEther VPN

SoftEther VPN is an open-source, user-friendly, multi-protocol VPN server that supports various VPN solutions, including OpenVPN and L2TP.

Building a Firewall

In many respects, the firewall works similar to a VPN gateway that sends all traffic to an on-premises system. The firewall instance needs to scan all traffic, so all traffic must go through it, meaning similar to a full VPN; all instances need to have their routes adjusted to the firewall.

Firewall rules and security groups are set up so that the instances cannot send traffic to the Internet directly. It is also recommended to disable the public IP address on the instances to avoid mistakes.