Product Documentation and Knowledge Base - HomeDocumentation


Charon-SSP


Example of a More Complex Network Configuration

Owned by W.Erber
Last updated: Feb 25, 2020Version comment
7 min read

Contents

Introduction to Example

(warning)  The customer is responsible for ensuring that any VPN solution and any access to the Internet meets the requirements of his or her company’s security guidelines. The example in this chapter is only for illustrative purposes. Please refer to the AWS documentation for up-to-date information.

(warning) Throughout this example, the physical interface names used on the Charon host are eth0 and eth1. If your instance supports enhanced networking, the interface names are in the format ensX. If this is the case, please review the section about interface names in AWS Networking and Charon-SSP before you create any interface configuration files.

This example is less a blueprint for implementation than an illustration of certain features of AWS networking. AWS offers prepackaged NAT and VPN gateways that can be used by customers for a fee. Such prepackaged solutions should be evaluated in addition to what is shown in this document.



This section describes a sample configuration as depicted below:


In this example, there are two Charon-SSP AWS instances:

  • Each instance has two Ethernet interfaces.
  • Both are connected to the same subnet. This enables IP communication between host and guest systems (no L2 protocols).
  • Only one instance (called the gateway in this section) has a public IP address on interface eth1.
  • The gateway offers a VPN connection to the customer network and a NAT service for Internet access to instances that only have private IP addresses (called clients in this section). The NAT service can be used by the Solaris guest. For the Charon-SSP AWS host with only private IP addresses the NAT connection implements the Internet access required for reaching the license servers.
  • On the instance with only private IP addresses (called the client in this section, one interface is dedicated to the host system, the other to a Solaris guest system.
  • The Solaris guest system can reach the customer network via the VPN and the Internet via the NAT service offered by the gateway.

The steps to implement the sample configuration are described below. It is assumed that you have launched two basic Charon-SSP AWS instances, one with an auto-assigned public IP address (the gateway) and one with a private IP address only (the client). At the beginning of, each instance should only have one Ethernet interface and they should be in the same subnet. The security group assigned should at least allow SSH to enable initial access. Allowing also ICMP makes testing easier.

(info) All IP addresses used in the description below refer to the sample configuration shown in the diagram.

(info) The client has IP connectivity only. For Layer 2 protocols, a bridge with VPN tunnel would have to be configured between client and gateway.

(warning) The configuration steps are based on the AWS environment at the time of writing. Changes in the AWS environment are outside the control of Stromasys.


Gateway Configuration

Activate the Second Network Interface with Elastic IP

  1. Create and attach a new interface with an Elastic IP address to your instance (see Network Management).
  2. Log into the gateway via SSH (see Accessing the Charon-SSP AWS Instance) using the auto-assigned public IP address.
  3. Become the root user (enter sudo -i).
  4. Create an interface configuration file for the second interface (if you are not sure about the correct name, review the AWS interface naming conventions). The file for the first interface should already exist.
    # cp /etc/sysconfig/network-scripts/ifcfg-eth0 /etc/sysconfig/network-scripts/ifcfg-eth1
  5. Edit this file, remove the hardware address line, and change the name of the interface to eth1.
  6. Restart the network (if the command fails, check your configuration for errors; you may also have to kill any running dhclient processes)::
    # systemctl restart network
  7. Your SSH session will be disconnected.

Expected result: 

  • After restarting the instance, the automatically assigned public IP address will be released by AWS. Until then, it can be used if a second routing table and routing rules are created to ensure correct traffic flow for each interface.
  • Gateway instance is reachable via Elastic IP address on eth1.

(info) The default gateway is automatically changed to eth1 with the Elastic IP address.

(info) In a VPC environment, auto-assigned private IP addresses are persistent (according to the AWS documentation at the time of writing).

Make the Client Instance Reachable from the Gateway

  1. Copy the private key required by the client to the gateway using SFTP (see Accessing the Charon-SSP AWS Instance).
  2. As the root user on the gateway copy the private key to ~sshuser/.ssh/. 
  3. Make the sshuser the owner of the .ssh directory and content:
    # chown -R sshuser:sshuser ~/sshuser/.ssh/
  4. Set permissions on the keyfile:
    # chmod 400 ~sshuser/.ssh/<keyfile>
  5. As sshuser log in to the client from the gateway via SSH (see Accessing the Charon-SSP AWS Instance).

Create an SSH VPN between Gateway and Customer Network

To create this VPN, follow the steps in SSH VPN - Connecting Charon Host and Guest to Customer Network.

Enable Routing on the Gateway

Since the gateway will have to forward packages from the client to the customer network and/or the Internet, IP forwarding must be enabled. In addition, AWS specific source/destination IP address checks must be disabled.

  1. Enable IP forwarding:
    # /sbin/sysctl -w net.ipv4.ip_forward=1
    (to make permanent: add the setting to /etc/sysctl.conf)
  2. Disable source/destination checking on all interfaces of the gateway instance:
    1. In the AWS EC2 dashboard, select Network Interfaces on the left.
    2. Select the interface representing eth0 of the gateway instance.
    3. Select Change Source/Dest. Check under Actions.
    4. Disable the check.
    5. Repeat steps b to d for eth1.
  3. Allow forwarding through firewall:
    # firewall-cmd --permanent --direct --add-rule ipv4 filter FORWARD 0 -i br_vpn0 -o eth0 -j ACCEPT
    # firewall-cmd --permanent --direct --add-rule ipv4 filter FORWARD 0 -o br_vpn0 -i eth0 -j ACCEPT

Adapt Security Group on Gateway

Change the security group content such that all traffic from the client is allowed.

  1. In the AWS EC2 dashboard, select Security Groups on the left.
  2. Select the security group used for the gateway instance.
  3. Select Edit Inbound Rules in Actions.
  4. Adapt the rules as required.
  5. If needed, repeat for outbound rules.

Set up NAT on the Gateway

To create a basic NAT configuration on the gateway instance, use the predefined zones internal and external of firewalld. Firewalld performs address translation between these two zones.

  1. Make sure the firewall is enabled.
  2. Move eth0 (with private IP address only) to the internal zone:
    # firewall-cmd --change-interface=eth0 --zone=internal --permanent
  3. Move eth1 (with public IP address) to the external zone:
    # firewall-cmd --change-interface=eth1 --zone=external --permanent
  4. Add DNS to the internal zone as an allowed service and add the web-cache port (required for license operation):
    # firewall-cmd --zone=internal --add-service=dns --permanent
    # firewall-cmd --zone=internal --add-port=8080/tcp --permanent
  5. Reload the firewall:
    # systemctl restart firewalld

Client Configuration

Change Default Route

The client should use the internal interface of the gateway as its default gateway.

  1. Delete the original default route:
    # ip route delete default via 172.31.32.1 dev eth0
  2. Add the new default route:
    # ip route add default via 172.31.44.94 dev eth0
  3. Make the route permanent by using the Network Settings option of Charon Manager and making the interface configuration static (manual configuration). Take care not to make your instance unreachable by entering incorrect data.

Adapt Security Group on Client

Change the security group content such that all required traffic from the customer network and other sources is allowed.

  1. In the AWS EC2 dashboard, select Security Groups on the left.
  2. Select the security group used for the gateway instance.
  3. Select Edit Inbound Rules in Actions.
  4. Adapt the rules as required.
  5. If needed, repeat for outbound rules.

Add a Non-Default DNS Server

The name resolution for the client does not seem to work with the default AWS name server (it works with the gateway instance). Configure a non-default name server (either a public name server on the Internet or a name  server in the customer network) by using the Network Settings option of the Charon Manager (add a non-default DNS server to the static interface configuration).

Configure Second Network Interface for Solaris Guest

The Solaris guest system should have a dedicated network interface. To achieve this, perform the following steps:

  1. Create a new network interface in the same subnet with only a private IP address and attach it to the running client instance (see Network Management). Make a note of the private IP address assigned to the interface.

  2. Create an interface configuration file for the second interface (if you are not sure about the correct name, review the AWS interface naming conventions). The file for the first interface should already exist.
    # cp /etc/sysconfig/network-scripts/ifcfg-eth0 /etc/sysconfig/network-scripts/ifcfg-eth1

  3. Edit this file to fit the characteristics of eth1. The private IP address used for this interface will be assigned to the Solaris guest. Therefore, configure the Linux Interface without IP address, similar to the following example:

    BOOTPROTO=none
    DEVICE=eth1
    NAME=eth1
    ONBOOT=yes
    TYPE=Ethernet
    USERCTL=no

  4. Make sure the default interface stays on eth0 by adding the following line to /etc/sysconfig/network:
    GATEWAYDEV=eth0

  5. Prevent the cloud setup from changing your network configuration by adding the following lines to /etc/cloud/cloud.cfg:
    network:
       ; config: disabled

  6. Restart the network (if the command fails, check your configuration for errors; you may also have to kill any running dhclient processes):
    # systemctl restart network

Expected result:

  1. The system should still be reachable via eth0.
  2. Interface eth1 should be up with out having an IP address configured.

Solaris Guest Configuration

Using the steps below, the Solaris guest system is configured to use the second NIC. The IP addresses used follow the example shown in the image above.

  1. Configure a guest Solaris system with eth1 as its interface. Set the MAC address to the same value as used by the host interface.
  2. Boot Solaris and configure the IP address assigned to interface eth1 for the Solaris Ethernet interface:
    # ifconfig hme0 172.31.45.229/20 (Solaris 10 example)
    or
    # ifconfig hme0 172.31.45.229 netmask 255.255.255.0     (Solaris 2.6 example)
    Make permanent by editing /etc/hosts and set the new address for the systems hostname. Then edit /etc/netmask and add the netmask for the subnet-network.
  3. Add default route on Solaris:
    # route add default 172.31.44.94
    Make permanent by editing /etc/defaultrouter and add the address of the gateway.
  4. Add DNS server to Solaris
    1. Edit /etc/resolv.conf and add a nameserver line for the DNS server.
    2. Make sure, DNS is used for hostname translation: # cp /etc/nsswitch.dns /etc/nsswitch.conf or edit nsswitch.conf to use files dns for the hostname resolution.

Remote Linux Configuration

In addition to setting up the SSH VPN tunnel as described in SSH VPN - Connecting Charon Host and Guest to Customer Network, you must set the route to the VPC subnet on the remote Linux system in order to be able to communicate with the client system there.

  • Example: # ip route add 172.31.32.0/20 via 192.168.0.10 dev br_vpn0

Result

The Solaris guest can reach the customer network via VPN and the Internet via NAT.


<Go to top>


© 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.