Network

Overview

Using the SysEleven Stack Network service, you can do much more than just accessing the internet; It's possible to build arbitrary private network topologies using virtual routers, networks, subnets, load balancers and VPN site connections.

Servers can access the internet using virtual routers (SNAT). For making servers and load balancers accessible from the internet, we offer a Floating IP service (DNAT).

You can improve security and control isolation by using security groups.

You can manage networking objects both via our public OpenStack API endpoints, as well as using the Dashboard.

Feature Support Matrix

OpenStack Neutron Feature CBK region DBL region
Basic networking yes yes
Floating IPs yes yes
Security groups yes yes
IPsec VPN (VPNaaS) yes yes
Customer public IP space (Bring your own IP) yes yes
L4 Load balancing (TCP) (Neutron-LBaaS) yes yes
L7 Load balancing (HTTP/HTTPS) (Octavia-LBaaS) yes yes
Neutron DNS integration and PTR records yes yes
Firewall rules (FWaaS) no no
Dynamic routing (BGP) no no
Metering support no no
Quality of service (QoS) no no
Service function chaining (SFC) no no
Port Trunking no no
IPv6 no no

Basic networking

OpenStack networks act as a virtual bridge.

You can associate one or more OpenStack subnets to your networks. You can use subnets to manage IP addresses and the DHCP server configuration.

Virtual machines and virtual routers use OpenStack ports to connect to virtual networks. When creating a port, you can let it choose a free IP address automatically for you, or assign a fixed IP address.

By creating different networks, you can have multiple isolated layer 2 networks. Different networks can use overlapping IP address spaces if you want, e.g. network A and network B can both use the same 10.0.10.0/24 prefix, if you don't plan to interconnect them.

It is not possible to bridge multiple networks. To communicate from network A to network B you need to use a router.

An OpenStack router is a virtual networking device that forwards data between different OpenStack networks and/or the internet.

For more information how you can connect different networks, have a look at our How-to guide on connecting two subnets with each other.

For internet access we provide a network called ext-net. Ports cannot be directly added to the ext-net external network for internet access (This is only possible with customer-owned bring-your-own-public-ip networks). To make virtual machines accessible from the internet, use Floating IPs or load balancers.

By default Port Security prevents spoofing attacks by only allowing the IP address/MAC address pair configured on the networking port. To allow different IP addresses/MAC addresses, you can disable port security or add additional allowed address pairs. You can find out more about port security here and have a look at our How-to for allowing additional subnets on a port. You need to allow different IP/MAC pairs as well if you want to use VRRP.

You can find an example heat template with a single network configuration in our GitHub repository.

Floating IPs

Floating IPs can be associated with virtual machines or load balancers, to make them accessible from the internet.

Security groups

A security group acts as a virtual firewall for servers and other resources on a network. It is a named collection of network access rules.

Rules can reference other security groups and can be even self-referencing.

Let's say you have backend servers, frontend servers, and database servers. You might create a security group for each and then define that backend servers can access database servers, while frontend servers cannot access database servers.

The default security group will be used if not specified otherwise. It allows all traffic in your OpenStack project that originates from a port with the default security group, and denies everything else.

We recommend not to block ICMP because path MTU discovery relies on it, to avoid connectivity issues over VPN tunnels.
For these reasons, ICMP packets from link local range 169.254.0.0/16 are explicitly allowed to enter any virtual machine in our cloud.
This is not a security concern, since this range is not routed in the Internet and between OpenStack networks.
If you configure an extra layer of security with iptables or other kind of filtering inside a virtual machine itself, please allow ICMP from this range.

IPsec VPN (VPNaaS)

With VPNaaS you can establish secure site-to-site tunnels from your premises to SysEleven Stack, so you can access cloud resources like if they were part of your network. This feature can also be used to interconnect different regions.

Currently our VPNaaS implementation supports the following algorithms in both phase 1 and 2:

Authentication
SHA-1
SHA-256
SHA-384
SHA-512
Encryption
3DES
AES-128
AES-192
AES-256
DH Groups
Group 2
Group 5
Group 14

See our heat-examples on GitHub for an example how to connect two regions using VPNaaS.

Known interoperability issues

As control over configuration details is limited in this VPNaaS implementation, connections to external destinations require flexibility on the remote side. For example there are multiple ways specified in IPsec how to connect multiple networks over a connection. Our VPNaaS supports only the variant, where each pair of networks uses a distinct SA (security association). This is known to cause problems hard to diagnose in conjunction with GCP Cloud VPN. One possible workaround is to set up distinct connections for each pair of networks, which can become awkward to maintain. Another would be to use a TCP VPN like OpenVPN, VTun, Wireguard, Tinc or Zerotier. As a third alternative approach, we are working on the preconditions needed to run virtual appliances like PFSense in our platform and let them provide self managed VPN services.

Customer public IP space (Bring your own IP addresses)

If you want to connect to the internet without NAT (e.g. using Fixed IPs instead of Floating IPs) or if you have special requirements, you can easily transfer your public IP networks to SysEleven Stack.

In addition to the standard ext-net, that is shared across all our customers, you will get your own external network. This gives you more control and can make it easier to integrate SysEleven Stack with your existing infrastructure.

Please contact our customer support if you are interested.

Load balancing

Using load balancers, you can improve the availability and scalability of your services.

SysEleven Stack offers two options: Neutron LBaaSv2 (TCP-only) and Octavia LBaaS (TCP, HTTP, HTTPS).

Octavia is currently in the public beta phase. This means we invite you to test Octavia load balancers, but we do not recommend you to use them for production workloads yet.

Please refer to the LBaaS reference documentation for a comparison between the two and for more information.

For how to get started, have a look at our LBaaS tutorial.

Neutron DNS integration and PTR records

The Neutron DNS integration adds dns_domain and dns_name attributes to networks, ports and floating IPs.

With these properties, the Neutron networking service will create forward A-type records and reverse PTR-type records in our Designate DNS service for you.

If you need to add a PTR-record to an existing floating IP, have a look at our how-to guide on adding PTR records to an existing floating IP.

If you are using a custom public IP space (Bring your own IP), you first need to delegate your corresponding in-addr.arpa to our DNS service before you can use the Neutron DNS integration.

Floating IPs with DNS properties

To create a reverse lookup PTR entry for a floating IP address, two parameters --dns-domain and --dns-name can be set. The DNS zone specfied in --dns-domain has to be created and owned by the same project. If the zone exists and configured properly, a forward A-type record as specified in --dns-name will be created in it. A reverse PTR-type record will be created in the in-addr.arpa zone that is hosted in our cloud, but invisible to customer projects.

The full command line to create a floating IP adress with a reverse PTR record will look like this: openstack floating ip create --dns-domain example.com. --dns-name mx01 ext-net

It is unfortunately not possible to set the dns_name and dns_domain properties for a floating IP that has already been created in the past.

Networks and ports with DNS properties

Forward A-type and reverse PTR-type records can be created automatically for all VMs that have Floating IP addresses attached. In order to achieve this, you need to provide the --dns-domain option when creating the network. It can also be updated later (e.g. using openstack network set example-network --dns-domain example.com.). You can create a network with the dns_domain property set using openstack network create example-net --dns-domain example.com..

The DNS zone specfied in --dns-domain must be created and owned by the same project. If the zone exists and is configured properly on a network, forward A-type records and reverse PTR-type records will be created for every VM in that network, as soon as a Floating IP address is attached to it.

The record name will be generated from the VM name. Note that some symbols like underscore (_) or spaces ( ) are not allowed in host names, and will be removed from the host name. When a Floating IP address is detached from a VM the corresponding A and PTR records are deleted automatically.

When using this approach, Floating IPs themselves don't need to be created using the --dns-domain and --dns-name options.