...

Introduction to Example

  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.

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

This section describes a sample configuration as depicted below:

Image Modified

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

• Each instance has two Ethernet interfaces.
• Both are connected to the same subnet.
• 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. The NAT service is possibly needed for the Solaris guest, but it is definitely needed for for an Charon-SSP AWS host with only private IP addresses to reach 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. 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.

 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:
   # 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:
   # systemctl restart network
7. Your SSH session will be disconnected.

Expected result: 

• Auto-assigned IP address is removed from eth0.
• Gateway instance is reachable via Elastic IP address on eth1.

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

...

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

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 pre-defined 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 pubilic 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. 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).

Add 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 client instance (see Network Management).
   
   
2. Create an interface configuration file for the second interface:
   # cp /etc/sysconfig/network-scripts/ifcfg-eth0 /etc/sysconfig/network-scripts/ifcfg-eth1


3. Edit this file, to fit the characteristics of eth1.
   1. You can use a manually configured private IP addresses as set when creating the interface in AWS. In this case, you must set the parameters similar to the following example:
      BOOTPROTO=none
DEVICE=eth1
      NAME=eth1
      ONBOOT=yes
TYPE=Ethernet
USERCTL=no
IPADDR=172.31.45.229
NETMASK=255.255.240.0
      
   2. Or, you can use the one automatically assigned to the interface during creation (persistent in VPC environment). In this case, set the parameters similar to the following example:
      BOOTPROTO=dhcp
DEVICE=eth1
NAME=eth1
ONBOOT=yes
TYPE=Ethernet
USERCTL=noDEFROUTE=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:
   # systemctl restart network


7. The system should still be reachable via eth0.
   
   
8. Create a separate routing table for eth1 (to workaround the forwarding problem created if traffic for the second interface is sent out through the first):
   # ip route add default via 172.31.44.94 dev eth1 table 1000
# ip route add 172.31.45.229 dev eth1 table 1000


9. Make routing table permanent by adding the information to /etc/sysconfig/network-scripts/route-eth1.
   default via 172.31.44.94 dev eth1 table 1000
172.31.45.229 dev eth1 table 1000
10. Add a rule to use the new routing table for all traffic from the eth1 interface IP address:
    # ip rule add from 172.31.45.229 lookup 1000 


11. Make rule permanent by adding the information to /etc/sysconfig/network-scripts/rule-eth1.
    from 172.31.45.229 lookup 1000
    
    
12. Remove the IP address from the interface (so it can be used by the Solaris guest):
    # ip addr delete 172.31.45.229/20 dev eth1
This must be added to a separate custom startup script.



...

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.

Image Modified