Contents

General Information

This section provides some basic information about networking questions that are likely to affect Charon-SSP when running in the cloud.

Please note:

• NetworkManager is disabled on Charon-SSP cloud-specific marketplace images (CentOS 7). Therefore, the interface configuration relies on ifcfg-files in /etc/sysconfig/network-scripts. For conventional RPM installations the basic network configuration environment used depends on the Linux image chosen to launch the instance. It is recommended to create the ifcfg-files for additional interfaces manually before using the Charon Manager to manage these interfaces.
• If the Charon host instance runs RHEL/CentOS 8.x, the network interfaces must be managed by the NetworkManager. The configuration can be set up via configuration files or nmcli commands. The Charon Manager ignores any interface that is not under NetworkManager control (unmanaged interfaces in the output of nmcli device).
• If the information in this chapter is not sufficient, please refer to the other Charon-SSP documentation provided by Stromasys and the documentation provided by your cloud provider for up-to-date and comprehensive information.

Host to Guest Communication Considerations

There are several ways a communication between the host operating system and the guest Solaris system can be implemented. For example:

1. Internal virtual bridge on the host system:
   Such a bridge has several TAP interfaces. The host and the guest systems are connected to this bridge and can communicate directly to one another using L3 and L2 protocols. The bridge uses its own IP subnet that can be defined by the user. Setting up such a configuration is supported by the Charon-SSP Manager (leave the default gateway field empty for the bridge interface). Several hosts configured with guest systems and such an internal bridge can communicate across the cloud-internal LAN and the host systems can route the private IP subnets of the bridges between themselves. L2 protocols are no longer possible if the routing across the cloud LAN is used.
2. Communication via the cloud-internal subnet LAN:
   In this case, a second interface is added to the Charon host system. The second interface is then assigned to the emulated guest system. After the correct configuration, the host and guest can communicate across the cloud-internal LAN using IP. L2 protocols or any protocols that require changing the MAC address to something different than the MAC address assigned to the second interface by the cloud provider will not work.
   To connect the guest system to the LAN, the following basic configuration steps must be performed:
   • Add the additional interface to the Charon host system.
   • Create a configuration file for the additional interface.
   • Remove the private IP address assigned to the second interface by the cloud provider from the Linux configuration (if it has been configured).
   • Use the Charon Manager to assign the interface to the emulated SPARC system.
   • Use the Charon Manager to set the MAC address of the emulated SPARC system to the same value as the one used on the host system Ethernet interface.
   • On the Solaris system, configure the private IP address that was previously assigned to the second interface on Linux and configure the appropriate default route for the LAN.

Please note:

• The section Dedicated NIC for Guest System provides some hints on how to configure the second interface in the different situations. Please refer to your cloud-provider's documentation for up-to-date comprehensive information.
• If Layer 2 communication between guests on different Charon hosts is required, a bridged tunnel solution must be set up between the two Charon host systems.

External Communication Considerations

In addition to allowing SSH access to the host system for management purposes, it may be necessary to enable Internet communication to the host and guest system or connect host and guest to the customer's network.

Please note: Charon hosts based on Charon-SSP AL (Automatic Licensing) marketplace images always need either direct Internet access or Internet access via NAT from a NAT gateway in the same cloud as the Charon host to access the license server.

Recommended way to connect the Charon host and Solaris guest systems to the customer network:

To ensure data traffic between the Charon host and guest systems and the customer network is encrypted, it is strongly recommended to use a VPN connection. An example of a simple VPN connection based on an SSH tunnel is described in SSH VPN - Connecting Charon Host and Guest to Customer Network. This connection is based on a bridge between Charon host and guest system and (via an encrypted SSH tunnel) the remote end-point in the customer network. The connection supports L3 and L2 protocols.

Cloud providers usually also provides a VPN gateway instance that can be added to the customer cloud network to connect the cloud network to the customer network (for a charge).

Recommended way to connect the Solaris guest system to the Internet:

The Internet connection can be implemented across the VPN to the customer network. In this case, the customer can allow the guest Solaris system to access the Internet exactly following the security policies defined by the customer.

Access to the Internet from subnets or a Solaris guest system with only private IP addresses:

Access to the Internet for subnets with only private IP addresses is possible across a gateway instance providing VPN access to the customer network and allowing (NATted) Internet access via this path. Alternatively, a NAT gateway in the cloud can be used to map the private addresses to public addresses. The NAT gateway can be implemented on a Charon host system or it can be often be provided by the cloud provider for a charge.

Please note: a Charon-SSP AL host system always needs either direct Internet access or Internet access via NAT from a NAT gateway in the same cloud as the Charon host to access the public license server.

Direct Solaris guest access to the Internet:

This not a recommended standard solution for security reasons. However, should it be required, two interfaces with public IP addresses can be assigned to the Charon host.
One of these interfaces is then dedicated to the guest system which uses the private interface address and the MAC address assigned to the Charon host by the cloud provider  (see also Dedicated NIC for Guest System).

Guest to Guest Layer 2 Communication Considerations

Should L2 protocols be required between two guest systems on different host systems, a bridge/tunnel solution similar to the one described in SSH VPN - Connecting Charon Host and Guest to Customer Network must be set up between the two host systems to allow the L2 traffic to pass.

Asymmetric Routing Considerations

This section applies to the case where several interfaces are configured on an instance and they all have IP addresses configured on the Linux level.

When you add a secondary NIC to a Linux instance, a new interface (that is, an Ethernet device) is added to the instance and automatically recognized by the OS. Depending on the cloud-provider, DHCP may not be active for the secondary VNIC, and you must configure the interface with a static IP address and add any routes that are relevant for the new interface.

Connectivity problems caused by asymmetric routing arise if traffic arrives through one interface and, when the service replies, the reply packets (with the incoming interface's IP address as the source address) go out the other interface. Policy-based routing is required to ensure that packets are sent out via the interface configured with the same IP address that is used as the source IP address in the packet, and to find the correct default gateway (if needed).

Please note:

• The steps below assume a RHEL or CentOS 7 system (as provided by the Charon-SSP marketplace images) where interfaces are managed outside the control of the NetworkManager. A RHEL or CentOS 8 system must use the NetworkManager to manage network interfaces. Please refer to your Linux documentation for details.
  
• The actual steps may vary slightly depending on the specific cloud environment. Please always refer to your cloud provider's documentation.

When adding a second IP interface on the Charon-SSP host, the routing problems described above can occur. To solve them, perform the following basic steps:

1. Create a configuration file (/etc/sysconfig/network-scripts/ifcfg-<interface-name>) for the second interface (if there is no configuration file for the primary interface, create it as well).
2. Set the correct interface for default route in /etc/sysconfig/network (example: GATEWAYDEV=eth0).
3. Restart the network.
4. Create an additional routing table (use the command: ip route add <path> dev <interface-name> table <table-id>). There must be an entry for every IP address assigned to the second interface and any other route to be used via this interface. The parameter <table-id> is a numeric value or the string default (for the main routing table).
5. Set rules in the Routing Policy Database (use the command: ip rule add from <ip-address-of-second-interface> lookup <table-id>)
6. If required, remove conflicting routes from the main routing table and add routing rules for the main routing table.
7. Create a static route file (/etc/sysconfig/network-scripts/route-<interface-name>)
8. Create a static rule file (/etc/sysconfig/network-scripts/rule-<interface-name>)

Please refer to the Linux man pages for ip rule and ip route for more information.

Additional information: the home directory of the sshuser contains a script named active_sec_network.sh. This script is only an example that illustrates how to create a systemd service to activate necessary routes and rules during system boot (instead of using steps 7 and 8 above). Do not use this script without carefully adapting it to your requirements - failing to do so, may make your system unreachable.

Cloud Instance and IP Forwarding

If a Charon cloud instance is to forward IP packages between its interfaces (act as a router), in addition to configuring IP forwarding on Linux (/sbin/sysctl -w net.ipv4.ip_forward=1), an additional configuration step is required in the configuration of the cloud instance. This configuration has different names in the different cloud environments.

• Source/Destination checking on AWS and OCI must be disabled for all relevant interfaces of the instance.
• IP forwarding on Azure must be enabled for all relevant interfaces of the instance.
• IP forwarding on GCP must be enabled for an instance when it is created.

Without this configuration, the cloud providers block packets that do not contain the IP address of the cloud instance interface in either the source or destination field.

Further Information

The following sections show sample network configurations:

• SSH VPN tunnel to connect Charon host and guest to remote systems or customer networks
• Dedicated NIC for the Solaris guest system