Contents

General Information

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

 NetworkManager is disabled on Charon-SSP OCI. Therefore, the interface configuration relies on ifcfg-files in /etc/sysconfig/network-scripts.

 The information in this chapter is not comprehensive. Please refer to the Oracle cloud documentation for up-to-date and comprehensive information.

Concepts

VCN: VCN stands for Virtual Cloud Network. Before you can launch an instance, you need to have a virtual cloud network (VCN) and subnet into which you can launch the instance. A VCN is associated with resources such as a CIDR address block, a route table, an Internet gateway, a default security list, etc.

Subnet: A subnet is a subdivision of the VCN. The subnet directs traffic according to a route table. For example, if you access the instance via a public IP address, the route table will direct traffic to an Internet gateway. A subnet also uses a security list to control traffic in and out of the instance.

Instance: An instance is a virtual machine that is launched into a VCN and subnet. It is associated with an image (e.g., Charon-SSP image) and a certain shape representing the virtual hardware.

VNIC: A virtual network interface card, which attaches to an instance and resides in a subnet to enable a connection to the subnet's VCN. The VNIC determines how the instance connects with endpoints inside and outside the VCN. Each instance has a primary VNIC that's created during instance launch and cannot be removed. All VNICs of an instance must be in the same availability domain as the instance.

Address Assignment

Each VCN is assigned a block of private IP addresses. This block can be split by the user to form several IP subnets. Routing within one VCN works automatically.

When an OCI instance is launched into a subnet,

• it is automatically assigned a private IP address from the address range assigned to the subnet,
• the user can choose whether to assign a public IP address if the subnet is a public subnet.

 Public IP addresses are not directly visible to the instance. The instance operating system always works with the private address. For external connections, the private address is mapped to the public IP address via NAT.

Reserved addresses (important, if manual address assignment is used):

The following address range is reserved, for example, to allow OCI to query meta-data about instance configuration: 169.254.0.0/16. This range is automatically configured on every network interface.

The following addresses are reserved in each subnet and cannot be used for instance VNICs (shown in the example below for network 10.1.1.0/24):

• 10.1.1.0: the network address
• 10.1.1.1: reserved by OCI for the default router
• 10.1.1.255: network broadcast address.

Other special addresses:

• 169.254.0.0/16: Reserved for OCI use.

Public IP addresses:

There are two types of public IP addresses (only available in public subnets):

• Ephemeral addresses:
  • maximum one per VNIC,
  • assigned by Oracle,
  • persistent during the lifetime of the associated private IP address,
  • can only be associated with the primary private IP address of a VNIC,
  • a user can only delete it but not associate it with a different private IP address.
• Reserved addresses:  
  • maximum 32 per VNIC,
  • created and assigned by the user,
  • can be re-assigned to a different private IP,
  • can be associated with primary and secondary private IP addresses,
  • exists until the user deletes it.

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 Manager.
2. Communication via the OCI 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 OCI 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 OCI will not work.
   To connect the guest system to the LAN, the following basic configuration steps must be performed (see also Dedicated NIC for Guest System):
   • 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 OCI 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 refer to the Oracle cloud 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.

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.

Oracle also provides a VPN connection solution that can be added to the customer VCN to connect the VCN 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 private VCN subnets or a Solaris guest system with only private IP addresses:

Access to the Internet for private VCN subnets 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 provided by OCI for a charge.
Please note that the Charon host always needs either direct Internet access or Internet access via NAT from a NAT gateway in the OCI cloud to access the 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 OCI (see also Dedicated NIC for Guest System).

Using a Charon host system as a Router

If a Charon host system is to be used as a router, it is not sufficient to configure Linux for IP forwarding.

The following settings have to be made on the Charon host instance via the OCI management console:

For each interface, the source/destination check has to be disabled (during creation of a VNIC or afterwards via the Edit VNIC function). Unless this is configured correctly, traffic from and to an OCI instance will only be allowed if either source or destination address belongs to the instance. Transit traffic destined to be forwarded by the router, would be discarded.

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 VNIC to a Linux instance, a new interface (that is, an Ethernet device) is added to the instance and automatically recognized by the OS. However, DHCP is not active for the secondary VNIC, and you must configure the interface with the static IP address and default route. If traffic arrives through a secondary VNIC's interface and the service replies, the reply packets automatically have the VNIC's interface IP address as the source IP address. Policy-based routing is required for that reply to go back out on the same interface and find the correct default gateway.

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.
5. Set rules in the Routing Policy Database (use the command: ip rule add from <ip-address-of-second-interface> lookup <table-id>)
6. Create a static route file (/etc/sysconfig/network-scripts/route-<interface-name>)
7. 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.

Further Information

The following sections show sample network configurations:

• SSH VPN - Connecting Charon Host and Guest to Customer Network
• Dedicated NIC for Guest System
  • Network and Guest Configuration on the Charon Host System
  • Network Configuration Steps on the Solaris Guest System