FarEye Blog

Establishing IPSec tunnel using Openswan tool on Amazon EC2

Posted on in Blog

Establishing IPSec tunnel using Openswan tool on Amazon EC2 (Ubuntu) to connect with Checkpoint VPN (Windows Server)

We struggled a lot to set this up initially due to lack of proper documentation. Hence we decided to share the steps with everyone.

Requirement
One of our client wanted to secure the communication between servers by encrypting it over an IPSec Tunnel.

Initial information provided to us
- Client was using Checkpoint VPN on Windows Server
- IP address of Checkpoint VPN endpoint : A.A.A.A
- IP address of the actual server, where communication was to happen: aA.aA.aA.aA (Both the IP's are on the same network/subnet)
- Client shared a secret key for setting up the tunnel

This is what we concluded

Client side network

Setting Environment on Amazon EC2

  1. Create a new Ubuntu box on EC2 (How to?)
  2. STRICT:  Use the latest release of Ubuntu. We used 64 bit, Ubuntu 14.04 OS
  3. STRICT:  Reserve an Elastic IP for this instance or else your IP will change with every reboot and the tunnel will stop working
    (This happened with us :-)
  4. SSH to Login
  5. Install Openswan: sudo apt-get install openswan
  6. STRICT: Openswan version must be > version 2.6

IP Details
- Elastic IP attached to EC2: B.B.B.B
- Internal IP attached to EC2: iB.iB.iB.iB

Updated network Daigram

Updated network diagram with EC2 IP

Start Setup

  1. Open Port 500 and 4500 for EC2 instance (Login to AWS Console and edit security rules of EC2)
     
  2. Run this command: sudo ipsec verify
    Expected output:
    Checking your system to see if IPsec got installed and started correctly:
    Version check and ipsec on-path                             [OK]
    Linux Openswan U2.6.38/K3.13.0-36-generic (netkey)
    Checking for IPsec support in kernel                        [OK]
    SAref kernel support                                       [N/A]
    NETKEY:  Testing XFRM related proc values                  [OK]
    [OK]
    [OK]
    Checking that pluto is running                              [OK]
    Pluto listening for IKE on udp 500                         [OK]
    Pluto listening for NAT-T on udp 4500                      [OK]
    Checking for 'ip' command                                   [OK]
    Checking /bin/sh is not /bin/dash                           [OK]
    Checking for 'iptables' command                             [OK]
    Opportunistic Encryption Support                            [DISABLED]

     

  3. Go ahead and update your ipsec.secrets  : sudo vim /etc/ipsec.secrets 
    # This file holds shared secrets or RSA private keys for inter-Pluto
    # authentication.  See ipsec_pluto(8) manpage, and HTML documentation.

    # RSA private key for this host, authenticating it to any other host
    # which knows the public part.  Suitable public keys, for ipsec.conf, DNS,
    # or configuration of other implementations, can be extracted conveniently
    # with "ipsec showhostkey".

    # this file is managed with debconf and will contain the automatically created RSA keys
    include /var/lib/openswan/ipsec.secrets.inc
    A.A.A.A 0.0.0.0 %any: PSK "you secret key within double qoutes"

     

  4. Update your ipsec.conf : sudo vim /etc/ipsec.conf
     
    config setup
            # Do not set debug options to debug configuration issues!
            # plutodebug / klipsdebug = "all", "none" or a combation from below:
            # "raw crypt parsing emitting control klips pfkey natt x509 dpd private"
            # eg:
            # plutodebug="control parsing"
            # Again: only enable plutodebug or klipsdebug when asked by a developer
            #
            # enable to get logs per-peer
            # plutoopts="--perpeerlog"
            #
            # Enable core dumps (might require system changes, like ulimit -C)
            # This is required for abrtd to work properly
            # Note: incorrect SElinux policies might prevent pluto writing the core
            dumpdir=/var/run/pluto/
            #
            # NAT-TRAVERSAL support, see README.NAT-Traversal
            nat_traversal=yes
            # exclude networks used on server side by adding %v4:!a.b.c.0/24
            # It seems that T-Mobile in the US and Rogers/Fido in Canada are
            # using 25/8 as "private" address space on their 3G network.
            # This range has not been announced via BGP (at least upto 2010-12-21)
            virtual_private=%v4:10.0.0.0/8,%v4:192.168.0.0/16,%v4:172.16.0.0/12,%v4:25.0.0.0/8,%v4:aA.aA.aA.0/24,%v6:fd00::/8,%v6:fe80::/10
            # OE is now off by default. Uncomment and change to on, to enable.
            oe=off
            # which IPsec stack to use. auto will try netkey, then klips then mast
            protostack=netkey
            # Use this to log to a file, or disable logging on embedded systems (like openwrt)
            #plutostderrlog=/dev/null
            interfaces="%defaultroute"
            #plutodebug="all"

    # Add connections here

    conn customer
            type=tunnel
            authby=secret
            left=%defaultroute
            leftid=B.B.B.B
            leftsourceip=iB.iB.iB.iB

            leftnexthop=%defaultroute
            leftsubnet=172.31.0.0/16 #Refer AWS Console VPC Subnet for correct value
            right=A.A.A.A
            rightid=A.A.A.A
            rightsubnet=aA.aA.aA.0/24 #Discuss with your client for an accurate value
            phase2=esp #Get this from Client
            phase2alg=3des-md5;modp1024 #Get this from Client
            ike=3des-md5;modp1024! #Get this from Client
            ikelifetime=480m #Get this from Client
            pfs=no #Get this from Client
            auto=start
            rekey=yes
            keyingtries=%forever

     

  5. Additional VPC Configuration:

    This was a step that we were missing for a long time. In order to get the VPC to correctly route traffic, you need to editing the routing tables at the VPC. Go to the AWS Console, then to VPC. Select ‘Route Tables’ and then click the Route Table that has a ‘No’ under ‘Main’. In it you should see something like

    Destination Target Status Actions
    10.0.0.0/16 local active iconactive

    Remove

    0.0.0.0/0 igw-c2749xxx active iconactive

    Remove

    This is sufficient for non-OpenSwan operation, but you’ll likely need to add in an extra rule to make it work. To do this,  set the destination to be the customer’s internal network (aA.aA.aA.0/24) and the target to be the EC2 instance running your OpenSwan tunnel (it should automatically show up there for you). Press ‘Add’ and make sure your table looks something like this:

    Destination Target Status Actions
    aA.aA.aA.0/24 eni-78759xxx / i-b8248xxx active iconactive

    Remove

    10.0.0.0/16 local active iconactive

    Remove

    0.0.0.0/0 igw-c27496a9 active iconactive

    Remove

 

You are Done !

ubuntu@ip-10-0-77-10:~$ sudo service ipsec status

sudo: unable to resolve host ip-10-0-77-10
IPsec running - pluto pid: 19080
pluto pid 19080
1 tunnels up
some eroutes exist

 

Tools to debug, in case tunnel is not up

ubuntu@ip-10-0-77-10:~$ route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
default 10.0.77.1 0.0.0.0 UG 100 0 0 eth0
10.0.77.0 * 255.255.255.0 U 0 0 0 eth0
192.168.8.0 10.0.77.1 255.255.248.0 UG 0 0 0 eth0

 

ubuntu@ip-10-0-77-10:~$ sudo ipsec whack --status

 

ubuntu@ip-10-0-77-10:~$ cat /var/log/syslog | grep ipsec

 

ubuntu@ip-10-0-77-10:~$ cat /var/log/auth.log | grep pluto

 

DON'Ts

  1. No need to make manual entry of SNAT and DNAT in IP Tables. Latest version of Openswan will handle it automatically
  2. No need of making any Firewall entries