Network Setup

Available ports

Resources in JSC Cloud are located in a dedicated DMZ at JSC, which determines the rules for accessing VMs and also for outbound network traffic. This results in a limited number of ports being available to offer services in virtual machines. For security considerations, inbound connections to JSC Cloud are limited to the following ports.

The following table contains the central firewall configuration. Whereas the OpenStack firewall can be configured at a user’s own discretion, the perimeter firewall imposes the rules as stated above.

Port

Purpose

Availabililty

80

HTTP

global

8008

HTTP-alt

global

8080

HTTP-alt

global

443

HTTPS

global

8443

HTTPS-alt

global

22

SSH

global

6443

Kubernetes API

global

7000-7020

general purpose, custom services

global

5432

PostgreSql DB

from HPC systems

3306

MySQL, MariaDB

from HPC systems

Users located at JSC may see a more liberal firewall policy, which should be taken into account when exposing services to the general public.

If your software insists on using a specific port and not be reconfigurable to any of the available ports, a local redirect may solve this problem for you. See below an example of redirecting port 80, which is available in JSC Cloud, to local port 8080, which is very often used by user managed web servers or development environments.

$ sudo iptables -t nat -A PREROUTING -p tcp --dport 80 -j DNAT --to-destination :8080

This will redirect external connections from outside the host. If you need the same redirection on localhost (IP address 127.0.0.1), then an additional rule is required to do this:

$ sudo iptables -t nat -A OUTPUT -p tcp -o lo --dport 80 -j REDIRECT --to-ports 8080

Please be sure to have a mechanism in place to persist these settings, so they will survive a reboot of the VM.

Outbound connections are possible with the sole exception of port 25/tcp, which is used for unauthenticated SMTP. If you need to send emails, then please use port 587/tcp to connect to your mail submission server.

If the available ports are not sufficient for your use-case, additional ports could be approved. However, this requires a detailed justification and should be an exception.

Saving floating IPs in OpenStack

In an OpenStack cloud, there are a limited number of floating IPs available. This means that it is not possible for each VM (instance) to have its own floating IP. However, there are several ways to work around this limitation and still provide access to your VMs. Here are three common methods:

Gateway/Jump Host

A gateway or jump host is a VM that has a floating IP and acts as a connection point to other VMs without floating IPs. To access a VM without a floating IP, you would first SSH into the gateway/jump host and then SSH into the target VM.

Ensure that the jump host has a floating IP that can be accessed from your local machine. Additionally, the jump host should have a private IP within the same subnet as the OpenStack instance’s private IP you want to access. Make sure the same SSH key pair is used for both the jump host and the private instance. Otherwise, you will need to explicitly specify the private key in the command or configuration as shown below.

+----------------------+                   +--------------------+               +-------------------------+
|  Personal Computer   |                   |    Jump Host       |               |   Private Instance      |
|  (Local Machine)     |<-- SSH -->        |   (Public IP)      |               |                         |
|  +-------------+     |                   |   +-------------+  |               |   +-------------------+ |
|  |  Local PC   |     |                   |   |  Private IP |  | <-- SSH -->   |   |  Private IP       | |
|  +-------------+     |                   |   +-------------+  |               |   +-------------------+ |
+----------------------+                   +--------------------+               +-------------------------+
           ^                                            |                                       ^
           |                                            |                                       |
    SSH connection                             SSH connection                         Private network
           |                                            |                                       |
           +--------------------------------------------+---------------------------------------+
                          Routed through Jump Host

The -J option in SSH allows you to specify a jump host to connect to a destination server. A jump host is an intermediary server through which the SSH connection is routed, useful for accessing private or isolated networks securely.

ssh -J <jump_user>@<floating_ip_of_jump_host> <destination_user>@<private_ip_of_instance>

Jump Host: The first server you connect to. Destination Host: The final server you want to access, typically behind the jump host.

Alternatively modify ~/.ssh/config on your local machine. Instead of typing the -J option every time, add an entry to your SSH config file (~/.ssh/config) to use the jump host for connections to the private instances:

Config Example:

Host jump
    HostName <floating_ip_of_jump_host>
    ForwardAgent yes
    User <jump_user>

Host dest
    HostName <private_ip_of_instance>
    User <dest_user>
    ProxyJump jump

After setting up the config file, you can directly ssh:

ssh dest

Reverse Proxy

A reverse proxy is a server that forwards client requests to other servers. In the context of OpenStack, a reverse proxy can be used to forward requests from a VM with a floating IP to other VMs without floating IPs.

To set up a reverse proxy:

Launch a VM and assign it a floating IP.
Install and configure a reverse proxy server (e.g., Nginx) on the VM with the floating IP.
Configure the reverse proxy to forward requests to the target VMs using their private IPs.

Load Balancer

A load balancer is a device that distributes incoming network traffic across multiple servers. In OpenStack, load balancers can be used to distribute traffic to other VMs without floating IPs.

To set up a load balancer:

Launch a VM.
Create a load balancer and configure it to distribute traffic to the target VMs using their private IPs.