Oracle Cloud Infrastructure Documentation

Access to Other Clouds with Libreswan

This topic shows how to connect your Oracle Cloud Infrastructure virtual cloud network (VCN) with another cloud provider by using an IPSec VPN with a Libreswan VM as the customer-premises equipment (CPE).

In the example shown here, the other cloud provider is Amazon Web Services (AWS). The connection is a secure and encrypted site-to-site IPSec VPN between the Oracle and Amazon environments. It enables resources in the two clouds to communicate with each other using their private IP addresses as if they are in the same network segment.

This configuration was validated using Libreswan version 3.23-4.

Route-Based VPNs with Libreswan

Libreswan supports both route-based and policy-based tunnels. The tunnel types can coexist without interfering with each other. The Oracle VPN headends use route-based tunnels. Oracle recommends that you configure Libreswan with the Virtual Tunnel Interface (VTI) configuration syntax.

Architecture

The following diagram shows the general layout of the connection.

This image shows the general layout of two clouds connected with an IPSec VPN and Libreswan CPE.

Required Personnel and Knowledge

Typically the following types of personnel are involved in setting up an IPSec VPN with Oracle Cloud Infrastructure:

  • Dev Ops team member (or similar function) who uses the Oracle Cloud Infrastructure Console to set up the cloud components required for the virtual network and IPSec VPN.
  • Network engineer (or similar function) who configures the on-premises router with information provided by the Dev Ops team member.

Tip

The Dev Ops team member must have the required permission to create and manage the cloud components. If the person is the default administrator for your Oracle Cloud Infrastructure tenancy or a member of the Administrators group, then they have the required permission. For information about restricting access to your networking components, see Access Control.

The personnel should be familiar with the following concepts and definitions:

cloud resources
Anything you provision on a cloud platform. For example, with Oracle Cloud Infrastructure, a cloud resource can refer to a VCN, compute instance, user, compartment, load balancer, or any other service component on the platform.
third-party cloud provider
Another cloud provider such as AWS. You must understand that cloud provider's provisioning and configuration process so you can create the resources required to establish an IPSec VPN between the third-party cloud and your Oracle Cloud Infrastructure VCN.
on-premises
A widely used term in cloud technologies that refers to your traditional data center environments. On-premises can refer to a colocation scenario, a dedicated floor space, a dedicated data center building, or a desktop running under your desk.
oracle cloud identifier (ocid)
A unique identifier assigned to each resource that you provision on Oracle Cloud Infrastructure. The OCID is a long string that Oracle automatically generates. You can't choose the value for an OCID or change a resource's OCID. For more information, see Resource Identifiers.

Information to Gather

The following table lists basic networking values required to set up the connection between the Oracle Cloud Infrastructure VCN and the AWS VPC. In the following table, "User" is you or someone in your company.

Value and Variable Used in the Config File Template Source Example Value and Notes

Oracle VCN CIDR block

${VcnCidrBlock}

User (Oracle)

172.0.0.0/16

The CIDR your company chose for your Oracle Cloud Infrastructure VCN.

AWS VPC CIDR block

User (AWS)

10.0.0.0/16

The CIDR your company chose for your AWS VPC.

AWS Libreswan public IP

${cpePublicIpAddress}

User (AWS)

AWS VM Public IP - 34.200.255.174

The public IP address for your Libreswan host.

AWS Libreswan local IP

${cpeLocalIP}

User (AWS)

AWS VM Private IP - 10.1.2.3

The IP address configured directly on your Libreswan host. If your host is not behind 1-1 NAT, this value is the same as the Libreswan public interface (34.220.255.174).

Oracle VPN headend IPSec tunnel endpoint (one per tunnel)

${ipAddress1}

${ipAddress2}

Oracle Console or API

Tunnel 1: 129.146.12.53

Tunnel 2: 129.146.13.53

The IP address that Oracle assigns for each tunnel when you create the IPSec connection between the DRG and CPE (see Configure Oracle Cloud Infrastructure DRG and CPE).

Oracle VPN tunnel shared secret (one per tunnel)

${psk1}

${psk2}

Oracle Console or API

Tunnel 1: EXAMPLEDPfAMkD7nTH3SWr6OFabdT6exXn6enSlsKbE

Tunnel 2: EXAMPLEDfeSD6VNe7OfelTIKfjbxWfejPniQkNDpfjh7dwL

The IPSec IKE pre-shared-key that Oracle assigns for each tunnel when you create the IPSec connection between the DRG and CPE (see Configure Oracle Cloud Infrastructure DRG and CPE).

Libreswan VTI labels (one per tunnel)

${vti1}

${vti2}

User

Tunnel 1: vti01

Tunnel 2: vti02

The name you assign to each tunnel's virtual tunnel interface. Each value must be unique on your Libreswan host.

Start the AWS Libreswan Configuration

  1. Using the AWS Console or APIs, create a Libreswan VM by using its provisioning process. Use Oracle Linux, CentOS, or Red Hat as the main operating system.
  2. After the new instance starts, connect to it with SSH and install the Libreswan package:

    sudo yum -y install libreswan
  3. In the AWS Console, disable the source and destination checks on the Libreswan VM instance by right-clicking the instance, clicking Networking, and then clicking Change Source/Dest. Check. When prompted, click Yes, Disable.

    This image shows the AWS Console dialog box for disabling the source/destination check on the Libreswan VM instance.

  4. On the Libreswan VM, configure IP_forward to allow AWS clients to send and receive traffic through the Libreswan VM. In the /etc/sysctl.conf file, set the following values and apply the updates with sudo sysctl -p.

    net.ipv4.ip_forward=1
    net.ipv4.conf.all.accept_redirects = 0
    net.ipv4.conf.all.send_redirects = 0
    net.ipv4.conf.default.send_redirects = 0
    net.ipv4.conf.eth0.send_redirects = 0
    net.ipv4.conf.default.accept_redirects = 0
    net.ipv4.conf.eth0.accept_redirects = 0
  5. In the AWS Console, edit your AWS route table. Add a rule with the VCN CIDR (172.0.0.0/16) as the destination and the AWS Libreswan instance ID (i-016ab864b43cb368e in this example) as the target.

    This image shows the AWS Console dialog box for editing a route rule.

  6. In the AWS Console, enable inbound TCP and UDP traffic on ports 4500 and 500 to allow Oracle Cloud Infrastructure IPSec VPN communication with the AWS Libreswan VM. This task includes editing both the AWS security groups and network ACLs. You can set the source value can be the Oracle public IP (the Oracle VPN headend IPSec tunnel endpoint) instead of 0.0.0.0/0.

    For security groups:

    This image shows the AWS Console dialog box for editing security group rules.

    For network ACLs:

    This image shows the AWS Console dialog box for editing network ACLs.

  7. Create the Libreswan IPSec configuration file:

    sudo mv /etc/ipsec.conf /etc/ipsec.conf.bck
    sudo vi /etc/ipsec.conf and include the following:
    config setup
    include /etc/ipsec.d/*.conf  
    

Configure Oracle Cloud Infrastructure DRG and CPE

  1. In the Oracle Console, create a customer-premises equipment (CPE) object that points to the Libreswan AWS instance public IP address (34.200.255.174).

    This image shows the Oracle Console for creating a CPE.

  2. If you don't already have a DRG attached to your VCN: in the Oracle Console, create a DRG and then attach it to the VCN (172.0.0.0/16).

    This image shows the Oracle Console for attaching a DRG to a VCN.

  3. In the Oracle Console, create an IPSec connection and point it to the AWS VPC CIDR (10.0.0.0/16). In other words, when you create the IPSec connection, set its static route to the AWS VPC CIDR.

    This image shows the Oracle Console for creating the IPSec connection.

    Oracle creates both tunnels and assigns these items to each one:

    • Oracle VPN headend IPSec tunnel endpoint (129.146.13.53 in the following image, which shows only one of the tunnels)
    • Oracle VPN tunnel shared secret (redacted in the following image)

    You can view these values by clicking the Actions icon (three dots) for the IPSec connection, and then clicking Tunnel Information. Initially each tunnel is in the DOWN state (offline) because you still have some additional configuration to do later on the AWS Libreswan VM.

    This image shows the Oracle Console and the tunnel state as DOWN.

  4. In the Oracle Console, edit the VCN's security rules to enable ingress TCP and UDP traffic on ports 4500 and 500 like you did the AWS security groups and network ACLs. You can use the AWS Libreswan VM public IP address instead of 0.0.0.0/0 if it's a persistent public IP. Also open all protocols and ports for ingress traffic from the AWS VPC CIDR (10.0.0.0/16). Remember: Security lists are associated with a subnet, so edit the security list associated with each subnet that needs to communicate with the AWS VPC. Or, if you're using VCN network security groups, edit the rules in the relevant NSGs.

    This image shows the Oracle Console and security list ingress rules.

  5. In the Oracle Console, edit the VCN's route tables to add a rule that has the AWS VPC CIDR (10.0.0.0/16) as the destination CIDR block and the DRG you created earlier as the target. Remember: Route tables are associated with a subnet, so edit the route table associated with each subnet that needs to communicate with the AWS VPC. The following screenshot shows the default route table for the VCN.

    This image shows the Oracle Console and route rules.

Set Up Your Configuration File: /etc/ipsec.d/oci-ipsec.conf

Use the following template for your /etc/ipsec.d/oci-ipsec.conf file. The file defines the two tunnels that Oracle creates when you set up the IPSec connection. Replace the variables such as ${ipAddress1} with your specific values (see the table in Information to Gather).

Important

If your CPE is behind a 1-1 NAT device, uncomment the rightid parameter and set it equal to the ${cpePublicIpAddress}.

conn oracle-tunnel-1
     left=${cpeLocalIP}
     # leftid=${cpePublicIpAddress} # See preceding note about 1-1 NAT device
     right=${ipAddress1}    
     authby=secret
     leftsubnet=0.0.0.0/0 
     rightsubnet=0.0.0.0/0
     auto=start
     mark=5/0xffffffff # Needs to be unique across all tunnels
     vti-interface=${vti1}
     vti-routing=no
     encapsulation=no
     ikelifetime=28800s
     salifetime=3600s
conn oracle-tunnel-2
     left=${cpeLocalIP}
     # leftid=${cpePublicIpAddress} # See preceding note about 1-1 NAT device
     right=${ipAddress2}
     authby=secret
     leftsubnet=0.0.0.0/0
     rightsubnet=0.0.0.0/0
     auto=start
     mark=6/0xffffffff # Needs to be unique across all tunnels
     vti-interface=${vti2}
     vti-routing=no
     encapsulation=no
     ikelifetime=28800s
     salifetime=3600s

Set Up Your Secrets File: /etc/ipsec.d/oci-ipsec.secrets

Use the following template for your /etc/ipsec.d/oci-ipsec.secrets file. It contains two lines per IPSec connection (one line per tunnel).

${cpePublicIpAddress} ${ipAddress1}: PSK "${psk1}"
${cpePublicIpAddress} ${ipAddress2}: PSK "${psk2}"

Reload the Libreswan Configuration

After setting up your configuration and secrets files, you must restart the Libreswan service.

Important

Restarting the Libreswan service may impact existing tunnels.

The following command rereads the config file and restarts the Libreswan service. If you're logged in with an unprivileged user account, you might need to use sudo before the command.

service ipsec restart

Check the Libreswan Status

Check the current state of your Libreswan tunnels by using the following command.

ipsec status

The tunnel is established if you see a line that includes the following:

STATE_MAIN_I4: ISAKMP SA established

In the future, if you need to open a support ticket with Oracle about your Libreswan tunnel, include the output of the preceding ipsec status command.

Check the Tunnel Interface Status

Check if the virtual tunnel interfaces are up or down by using the ifconfig command or the ip link show command. You can also use applications such as tcpdump with the interfaces.

Here's an example of the ifconfig output:

ifconfig
<output trimmed>
				
vti01: flags=209<UP,POINTOPOINT,RUNNING,NOARP> mtu 8980
     inet6 fe80::5efe:a00:2 prefixlen 64 scopeid 0x20<link>
     tunnel txqueuelen 1000 (IPIP Tunnel)
     RX packets 0 bytes 0 (0.0 B)
     RX errors 0 dropped 0 overruns 0 frame 0
     TX packets 0 bytes 0 (0.0 B)
     TX errors 10 dropped 0 overruns 0 carrier 10 collisions 0

vti02: flags=209<UP,POINTOPOINT,RUNNING,NOARP> mtu 8980
     inet6 fe80::5efe:a00:2 prefixlen 64 scopeid 0x20<link>
     tunnel txqueuelen 1000 (IPIP Tunnel)
     RX packets 0 bytes 0 (0.0 B)
     RX errors 0 dropped 0 overruns 0 frame 0
     TX packets 0 bytes 0 (0.0 B)
     TX errors 40 dropped 0 overruns 0 carrier 40 collisions 0

Here's an example of the ip link show output:

ip link show
<output trimmed>

9: vti01@NONE: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 8980 qdisc noqueue
state UNKNOWN mode DEFAULT group default qlen 1000
   link/ipip 10.0.0.2 peer 129.146.12.53

10: vti02@NONE: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 8980 qdisc noqueue
state UNKNOWN mode DEFAULT group default qlen 1000
   link/ipip 10.0.0.2 peer 129.146.13.53

Also, in the Oracle Cloud Infrastructure Console, each IPSec tunnel should now be in the UP state.

This image shows the Oracle Console and the tunnel state as UP.

Configure IP Routing

Use the following ip command to create static routes that send traffic to your VCN through the IPSec tunnels. If you're logged in with an unprivileged user account, you might need to use sudo before the command.

ip route add ${VcnCidrBlock} nexthop dev ${vti1} nexthop dev ${vti2}
ip route show

Test the Connection

Now that the tunnels are up, you can test whether an Oracle Cloud Infrastructure VM can communicate with an AWS VM over the IPSec connection. One easy way is with the ping command. The following example shows a successful ping from each side of the connection. The VMs from both cloud providers can communicate with each other.

This image shows the results of the ping tests from each side of the connection.