__Include: How to Use an SSH VPN to Charon Host and Guest

Contents

Applicable Charon Products

The configuration shown in this chapter should work for any Charon product.

Prerequisites:

  • Charon host system is a supported Linux system.
  • The product must support TAP interfaces for the emulated system Ethernet interface.
  • The remote endpoint is a Linux system.

Overview

If the connection between the Charon host system, including the configured legacy guest systems, and the rest of the customer’s network runs over a public network as is the case for Charon in cloud environments it is necessary to secure the traffic against unauthorized access.

The example in this section describes how to configure a bridged SSH-based VPN tunnel between the Charon host and a remote Linux system across a public network. 

Please note:

  • The customer is responsible for ensuring that any VPN solution meets the requirements of his or her company’s security guidelines. The example in this chapter is only for illustrative purposes.
  • The advantage of a bridged connection is that L2 protocols are also supported.

Once the sample configuration has been set up, it can be used for

  • communication between host and guest system,
  • communication between customer network and guest system.

The following image shows an overview of the sample topology:

Prerequisites

The example shows how to create a local virtual bridge connecting host and guest system on the host, and a set of commands on the remote Linux System to create an SSH VPN tunnel.

For this configuration to work, the following prerequisites must be met:

  • The remote Linux system must have access to the public IP address and the SSH port of the Charon host.
  • The private key necessary to access the instance must be available on the remote Linux system and the public key must be installed on the Charon host system for the user used to set up the tunnel.
  • autossh package must be installed on the remote Linux system.
  • If using the Charon-SSP Manager on a Linux 7.x system, the bridge-utils package is also required.

Key-Pair Creation and Public Key Installation on Host System

The SSH tunnel requires a key-pair consisting of a private and a public key. The private key is used by the remote Linux system to identify itself with the Charon host system, which must have the matching public key installed.

The creation of the key-pair and the installation of the public key require different steps depending on the Charon product used.

Conventional Linux Installation

Creating a Key-Pair 

This step is performed on the remote Linux system that will be used as the tunnel end-point.

Please note: If the key-pair is not created automatically during the launch of the instance, you can create it using a command similar to the following:
   Sample 1: # ssh-keygen -t rsa -b 4096 -f ~/.ssh/<keyname> -q
   Sample 2: # ssh-keygen -t ecdsa -f ~/.ssh/<keyname> -q

By default, the key files are stored in the .ssh directory of the current user. The resulting key-pair can then be associated with instance during instance creation or later by adding it to the authorized_keys file of the correct user on the target system. This will allow the key to be used to create an encrypted SSH connection.

Please note: if your management system supports it, for RHEL 9.x, Rocky Linux 9.x, and Oracle Linux 9.x use SSH key types ECDSA or ED25519. This will allow connecting to these Linux systems using an SSH tunnel without the default crypto-policy settings on the Charon host having to be changed for less secure settings. See also: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html/security_hardening/using-the-system-wide-cryptographic-policies_security-hardening.

Installing the Public Key on the Charon Host

Connect to the Charon host (as user root) via SFTP or SCP and copy the public key file to the system. The following example shows the steps for SFTP:

$ sftp root@<charon-ssp-host-ip>

sftp> put <path-to-public-key> <keyname>.pub

sftp> bye

Log in to the Charon host system and add the content of <keyname>.pub to /root/.ssh/authorized_keys (using a text editor). Make sure, the file permissions of the authorized_keys file are set such that the owner has read/write access to the file and others have no access. If required, also add restrictions regarding the allowable commands to the file using the ‘command=”filename’ command at the beginning of the line containing the SSH key.

Charon Cloud-Specific Marketplace Images

The key-pair is (optionally) created and then assigned to the Charon cloud instance at first launch. If a new key-pair is created, the private key can be downloaded during creation.

Make sure to store the private key in a safe place. If it is lost, access to the instance may be permanently lost.


Adapting the SSH Daemon Configuration of the Charon Host System

The default configuration of the SSH daemon must be adapted to allow tunnel setup and root login by SSH key only. To do this, perform the following steps:

  1. Login as the root user.
  2. Open the file /etc/ssh/sshd_config with a text editor.
  3. Set the following parameters:
    PermitRootLogin without-password
    PermitTunnel yes
  4. Restart the SSH service:
    # systemctl restart sshd

Setting up the VPN Tunnel

The image below shows a more detailed picture of the connection between the remote Linux system and the Charon host. This section describes how to configure this sample setup.


Steps on the Charon Host System

Creating a VPN Bridge Manually

Please note: should you plan to manage this bridge later using the Charon Manager, you must adhere to the Charon-SSP naming conventions for virtual bridges:

  • Bridge name: br_<name-of-bridge>
  • TAP name for emulator connection: tapX_<name-of-bridge> (where X stands for an integer identifying the tap interface)
  • TAP name for tunnel connection: tap0

To create a bridge for the VPN tunnel manually, use commands similar to the following:

ip tuntap add dev tap0_vpn0 mod tap
ip link set tap0_vpn0 up

ip tuntap add dev tap0 mod tap
ip link set tap0 up

ip link add name br_vpn0 type bridge
ip link set br_vpn0 up
ip addr add 192.168.0.10/24 dev br_vpn0

ip link set tap0_vpn0 master br_vpn0
ip link set tap0 master br_vpn0

The above commands are not persistent across reboots.

To make the configuration permanent, you can use ifcfg-files, nmcli commands, or a custom startup script - depending on your requirements and your host operating system version.

Linux versionnetwork-scripts method (ifcfg-files)NetworkManager (nmcli)
7.x

Installed by default.

NM_CONTROLLED=no forces ifcfg-file use

Installed by default.
8.x

Deprecated but available;
needed if TAP interfaces are to be configured in ifcfg-files.

Preferred configuration method.
Used by the Charon-SSP Manager starting with Linux 8
9.xNo longer available.
For interface types supported by the ifcfg-rh plugin, ifcfg-files can be used.
Only method with full functionality.
Must be used for TAP interfaces.


Sample ifcfg-files for CentOS/RHEL 7:

# cat /etc/sysconfig/network-scripts/ifcfg-br_vpn0
DEVICE=br_vpn0
NAME=br_vpn0
TYPE=Bridge
ONBOOT=yes
DEFROUTE=yes
STP=no
BOOTPROTO=none
IPADDR=192.168.0.10
NETMASK=255.255.255.0
NM_CONTROLLED=no

# cat /etc/sysconfig/network-scripts/ifcfg-tap0
DEVICE=tap0
NAME=tap0
BRIDGE=br_vpn0
TYPE=Tap
ONBOOT=yes
NM_CONTROLLED=no

# cat /etc/sysconfig/network-scripts/ifcfg-tap0_vpn0
DEVICE=tap0_vpn0
NAME=tap0_vpn0
BRIDGE=br_vpn0
TYPE=Tap
ONBOOT=yes
NM_CONTROLLED=no

Note that on CentOS/RHEL 8 the interfaces must be under NetworkManager control (that is, the NM_CONTROLLED command must be removed or set to yes) if the interfaces are later to be managed by the Charon-SSP Manager.

Please note that the network-scripts package is no longer available in RHEL 9 and derivatives. While the ifcfg-rh plugin can handle many of the legacy ifcfg file configurations, it cannot handle TAP interfaces. Therefore nmcli should be used to make the bridge configuration permanent (as shown in the sample below).

nmcli conn add type bridge con-name br_vpn0 ifname br_vpn0 ipv4.method manual ipv4.addresses 192.168.0.10/24 \ 
      ipv6.method disabled
nmcli conn add type tun mode tap autoconnect yes con-name tap0_vpn0 ifname tap0_vpn0 master br_vpn0

Creating a VPN Bridge using the Charon-SSP Manager

To configure the SSH VPN connection, you must setup a private VPN bridge (called a virtual network in the Charon context) using the Charon Manager. Use the following steps to perform this task:

1. Open the Charon-SSP Manager and log in to the Charon-SSP host.

2. In the Charon Manager, open the Network Settings window by clicking on Tools > Network Settings. This will open the Network Settings window.

3. Click on Add and then on Virtual Network to open the virtual network configuration window. This will open the Add Virtual Network configuration window as shown below.

4. Enter the required information as shown below:

Perform the following steps to configure a VPN bridge:

  • Set Create for SSH VPN to ON,
  • Enter the Number of virtual adapters (TAP interfaces) required. These interfaces will be assigned to the emulated SPARC systems as Ethernet interfaces.
  • Configure the IP address for the bridge interface.
  • Set the Netmask.

Please note: this interface and the interface on the remote Linux system must be in the same IP subnet.

Click on OK to save your configuration.


Assigning the Guest Ethernet Interface

All Charon Emulator products

Adapt the configuration file to use the tap0_vpn0 interface in the above example for the emulated Ethernet interface.

Charon-SSP Manager

One of the TAP interfaces created in the step above, must be assigned to the Solaris guest system to add it to the LAN that will be tunneled across SSH to the remote Linux system.

Perform the following steps:

1. Open the Charon-SSP Manager and log in to the Charon-SSP host.

2. In the Charon Manager, select the guest system and then the Ethernet configuration category on the left. Assign one of the created TAP interfaces to the guest (see example below).

Click on OK to save the configuration change.

If the emulated instance is currently running, the guest must be shut down and the emulated instance must be restarted for the change to become active.


Steps on the Remote Linux System

Please note: the steps on the Charon host must be performed first.

As the user root on the remote Linux system, perform the following steps to set up the VPN tunnel according to the overview image above:

ActionCommand
Create TAP interface# ip tuntap add dev tap0 mod tap
Enable TAP interface# ip link set tap0 up
Create bridge# ip link add name br_vpn0 type bridge
Enable bridge interface# ip link set br_vpn0 up
Define IP address for bridge# ip addr add 192.168.0.1/24 dev br_vpn0
Add TAP interface to bridge# ip link set tap0 master br_vpn0

Start  the SSH tunnel

autossh is a program to start a copy of ssh and monitor it, restarting it
as necessary should it die or stop passing traffic.

Once started, you can move the program to the background.

# autossh -M 9876 -o ServerAliveInterval=60 -o Tunnel=ethernet \
  -w 0:0 -t -i <path-to-private-key> -NCT <username>@<public-AWS-instance-IP>

    The value for username depends on the Charon product: 

All products: root (or another configured user with the correct privileges and authorized_keys file).
Charon-SSP Baremetal and Charon marketplace images: sshuser 

-M defines the monitoring port autossh uses to monitor the connection
-o  sets SSH options (bridged tunnel and keepalive)
-i   denotes the path to the private key matching the public key copied to the host system.
-w denotes the number of the local and remote tunnel interfaces for tunnel device forwarding
     (e.g., the 0 in interface tap0). 
-N denotes that no remote command should be executed
-T disables pseudo-terminal allocation
-C requests data compression


Steps on the Guest System

Set the IP address on the Ethernet interface to an address within the VPN subnet. To follow the example above, you would set the address to 192.168.0.33/24. 

Making the configuration permanent on a Solaris system (as an example):

  • Change the address in /etc/hosts for the hostname specified in /etc/<interfacename>.hostname.
  • On Solaris 11, use the commands ipadm create-ip netX and ipadm create-addr -T static -a <ip-address>/<netmask> netX/v4.

Functionality after Creating the Tunnel

After the tunnel has been created, the guest system can communicate with

  • the Charon host system, and
  • the remote Linux system.

Routing between the Guest System and the Customer Network 

After following the description above, the guest system can be reached from the systems that are also connected to the virtual bridge (in the example: remote Linux system and host system). To enable the guest system to communicate with other systems in the customer network (or the Internet) over the VPN connection, perform the following steps:

Steps on the Guest System

Add the VPN address of the remote Linux system as the default gateway for the guest system. To follow the example above, use the command

# route add default 192.168.0.1

Steps on the Remote Linux System

To turn the remote Linux system into a router for other systems in the customer network, perform the following steps:

  1. Enable IP Forwarding using the command:
    # sysctl -w net.ipv4.ip_forward=1
    To make permanent, add net.ipv4.ip_forward=1 to the file /etc/sysctl.conf.
  2. If the Linux firewall is enabled (firewalld assumed), allow the forwarding of packets through the firewall:
    # firewall-cmd --permanent --direct --add-rule ipv4 filter FORWARD 0 -i <tunnel-bridge-interface> -o <NIC-to-LAN> -j ACCEPT
    # firewall-cmd --permanent --direct --add-rule ipv4 filter FORWARD 0 -o <NIC-to-LAN> -i <tunnel-bridge-interface> -j ACCEPT

Steps on Other Systems in the Customer Network

To enable communication between other systems in the customer network, configure a static route to the SSH tunnel LAN subnet via the Linux router.

Functionality after Setting up the Sample configuration

After the sample configuration has been created, the Solaris guest can communicate with

  • the Charon host system,
  • the remote Linux, and
  • other systems on the customer LAN that have been configured with the correct route via the Linux router.

Sample output from a system inside the customer LAN:

  • IP address in different IP subnet
  • Routing entry via the Linux router
  • Ping to guest system


Sample login to the guest system from host inside customer LAN:



© Stromasys, 1999-2024  - All the information is provided on the best effort basis, and might be changed anytime without notice. Information provided does not mean Stromasys commitment to any features described.