Contents

Overview

If the connection between the Charon-SSP host system, including the configured Charon-SSP guest systems, and the rest of the customer’s network runs over a public network as is the case for Charon-SSP instances hosted in a cloud, 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-SSP host and a remote Linux system across a public network. Topologies that are more complicated will require other, more sophisticated, solutions.

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 tunnel in this example has two endpoints:

• The remote Linux system: in this example, this system could be in the customer on-premises network and use the tunnel configuration to connect across the Internet to a Charon-SSP host system in the cloud. If in conformance with the customer security policies, the configuration could be expanded to make this Linux system the router between the customer network and the Charon-SSP host system (optionally including guest systems) in the cloud.
• The Charon-SSP host system: in this example, the Charon host system could be in a public cloud and require a connection to other customer devices across the Internet.

Prerequisites

The example shows how to use the Charon Manager on the Charon-SSP 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-SSH host instance in the cloud.
• The private key necessary to access the instance must be available on the remote Linux system. The key-pair required to access the cloud instance is typically associated with the instance when it is created.
  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
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, and then 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.

• If the Linux host system runs RHEL, CentOS, or Oracle Linux 7.x the bridge-utils package must be installed, if the Charon Manager configuration options (vs. manual configuration) are to be used.

• The autossh package must be installed on the remote Linux system.
• The Charon host must allow SSH tunnels. This is preconfigured on Charon-SSP marketplace images. On conventional RPM installations, make sure that PermitTunnel is set to yes in /etc/ssh/sshd_config. If the root user is to be used for the tunnel creation, a key-based login should be set up for this user (PermitRootLogin set to without-password), Restart the SSH daemon after changes to the file (# systemctl restart sshd).

Setting up the VPN Tunnel

The image below shows a sample setup. This section describes how to configure this sample setup.

Steps on the Charon-SSP Host System

Creating a VPN Bridge

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:

To learn more about the virtual network configuration options, refer to section Host System Network Configuration in the general Charon-SSP User's Guide. 

Assigning the Guest Ethernet Interface

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.

Please note: 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 effective.

Steps on the Remote Linux System

Please note: the steps on the Charon-SSP 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 (the ip commands are not persistent across reboots; they should be put into a script once the configuration is working):

Possible additional steps:

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. Basic example:
   # 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
3. Add static or dynamic routes to distribute the tunnel subnet to other systems in the customer network that need to communicate with the Solaris guest system across the VPN..

Steps on the Solaris 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. To permanently change the IP address on the Solaris system, 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.

Routing to/from Solaris Guest 

After following the description above, the Solaris 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 Solaris guest system to communicate with other systems in the customer network (or the Internet) over the VPN connection, perform the following steps:

• Add the VPN address of the remote Linux system as the default gateway for the Solaris guest system.
• Propagate the IP network used for the SSH VPN within the customer network, as required.
• Enable IP forwarding on the remote Linux system and allow forwarded packages through the firewall.

The screenshot below illustrates the Solaris guest system behavior (after the VPN network has been made known within the customer LAN and the remote Linux host has been set up as a router):

• The interface address shows that the Solaris system is in the 192.168.0.0/24 network using the ifconfig command.
• The netstat -rn command shows the routing table without a default route.
• The ping to an IP address outside the SSH VPN fails.
• The route add default <gateway> command adds the remote Linux host as the default gateway.
• The  netstat -rn command now shows the default route.
• The ping to an IP address outside the SSH VPN succeeds.

To make the entry permanent 

• on Solaris 10: use the route -p command (stores routes in /etc/inet/static_routes).
• on older Solaris versions: add the address of the default gateway to /etc/defaultrouter. 

Stopping the SSH Tunnel

To stop the SSH tunnel, perform the following steps on the remote Linux system: