What the IPSEC are you talking about?

What is IPsec?

Most of the time when we are trying to establish a site-to-site or LAN-to-LAN connectivity between two independent parties over an untrusted medium we rely on IPsec. Internet Protocol Security (IPSec) is a open standard suite of protocols used to authenticate and encrypt IP Packets in a connection. This ensures data integrity and data confidentiality. IPsec can be used in a variety of ways, to secure host-to-host communication, network-to-network communication, host-to-network. The most common type is network-to-network. An argument can be made that host-to-host is the same as network-to-network with /32s (i.e. 192.168.1.1/32 to 192.168.255.1/32). Anyway!

IPsec allows us to form a secure virtual communication link over a untrusted medium such as the internet to allow LAN to LAN communication. Sound familar? VPN anyone? For instance if CompanyA with 192.168.1.0/24 address space and CompanyB with 172.16.1.0/24 address space require hosts on each of their networks to talk to one another, this can be accomplished by utilizing a IPsec tunnel. Hosts at CompanyA would be able to traverse the IPsec tunnel to CompanyB as it appears to them to be nothing more than another routed LAN. It’s a cheap and easy way to create this linked infrastructure without the need to buy or lay-down physically dedicate cabling. Why not piggy back and on an already existing insecure circuit and make it secure with IPSec!!

Phase 1 and Phase 2 ???

“Phase 1” — Before IPsec can even begin to send your data, there is a negotiation and the establishment of an agreed upon method to create and secure this connection. The negotiation is performed by Internet Key Exchange (IKE), which consists of (I think) 3 different Key Management protocols. ISAKMP, Oakley, SKEME. All of which are used based on how you want to setup the key exchange, ISAKMP being the most popular. The main point of this Phase 1 is two things, one to agree upon a way to protect this negoitation, followed by authenticating each endpoint to form a trust relationship. This all happens bidirectionally. Once both of those have been completed we have a successfully formed a IKE Security Association(SA) that maintains this trust. IKE uses the key exchange algorithm called Diffie-Hellman to establish a secret key between each end. After this secure channel is setup it will be used in the next phase to negotiate the IPsec SAs, creatively called “Phase 2”. Keep in mind thata single Phase 1 SA can house multiple IPSec SAs!!!, unless you are using Perfect Forward Security(PFS). PFS make it so each IPSec tunnel has only 1 unique Phase 1 SA, that way if Phase 1 is ever compromised it won’t jeopardize all your IPSec tunnels under a single Phase 1 SA. Did I lose you? 🙂

“Phase 2” — IKE is used to negotiate IPSec SAs and how IPSec should be protected. In this Security Association (SA), the actual networks at each end of the tunnel must be agree upon. If they are not, Phase 2 will never come up as their SA are in mismatch. Furthermore, in this Phase 2 an agree upon Transform-set is established. The Transform-Set is the method on how the packets will be encrypted and transmitted out the tunnel interface. How should we transform the packets through the tunnel? Phase 2 also uses the key exchanged from Phase 1 to be used when encrypting the data. If PFS is used, keys are derived independently and not from Phase 1. The cost being time, benefit being a single key compromise does not compromise all IPSec tunnels. Keep in mind Phase 2 is required to be completed at both ends. If not the opposing side won’t know how to decrypt the data!!

So in summary IKE is used to protect Phase 1 and Phase 2, IPSec is used to send the packets. If you want to understand these steps further, I recommned reading this overview. It is a great explaination. Also if you haven’t already bookmark PacketLife.net!!

Tunnel vs Transport ??

Difference between Tunnel and Transport mode is in Tunnel mode the complete Original IP packet header information is encapsulated and encrypted, in Transport mode only the TCP/UDP payload is encrypted.

***Source– https://www.slideshare.net/keshabnath/ip-security-19425154***

The Design:

Openswan U2.6.37/K3.2.0-4-amd64 w/NetKey Support connecting to a Cisco ASA 5505 running version 9.1(3). I include the versioning because I read a lot of articles where the version of OpenSwan matters tremendously, and also seems to influence what types of issues you might run into. The version I am running uses a fairly new feature called NetKey. From my research this was introduced to make configuring a IPSEC tunnel easier and not require the re-compiling of the Linux Kernel.

Network info:

Openswan is authoritative for 172.16.255.1/32 network, which is a single host only. The 172.16.255.1 is also loopback NIC interface on the Openswan box itself. This is not required if you have a network that ties directly into the Openswan box.

root@vps1:/# ifconfig lo:1
lo:1      Link encap:Local Loopback
          inet addr:172.16.255.1  Mask:255.255.255.255
          UP LOOPBACK RUNNING  MTU:16436  Metric:1

Or..edit your /etc/network/interfaces config file.

auto lo:1
        iface lo:1 inet static
        address 172.16.255.1
        netmask 255.255.255.255

NOTICE: Your setup may be different. If your Openswan box is acting as a Router and performing NAT’ing you will include which subnets inside your network that you want to traverse the IPSec tunnel.

Cisco ASA is authoritative for 192.168.1.0/24, which is a single /24 network behind the Firewall.

asa# show ip
System IP Addresses:
Interface                Name                   IP address      Subnet mask     Method
Vlan1                    inside                 192.168.1.1     255.255.255.0   CONFIG

Phase 1 Parameters:
Encryption = 3DES
Integrity Hash = MD5
Diffie–Hellman = Group 2 (1024-bit)
IKE lifetime = 86400s

Phase 2 Parameters:
Encryption = ESP-3DES
Integrity Hash = ESP-MD5

Configuration Time!

OpenSwan Side:

root@vps1:~# apt-get install openswan ntp ike-scan ipsec-tools
root@vps1:~# mv /etc/ipsec.conf /etc/ipsec.conf.bak
root@vps1:~# vi /etc/ipsec.conf

Needed for Debian:

echo "net.ipv4.ip_forward=1" >> /etc/sysctl.conf
echo "net.ipv4.conf.all.send_redirects=0" >> /etc/sysctl.conf
echo "net.ipv4.conf.all.accept_redirects = 0" >> /etc/sysctl.conf

######/etc/ipsec.conf#######
config setup
        listen=x.x.137.133
        plutodebug=none
        klipsdebug=none
        plutoopts="--perpeerlog"
        
        nat_traversal=yes
        virtual_private=%v4:172.16.255.1/32,%v4:192.168.0.0/24
        oe=off #opportunistic encryption is off
        protostack=netkey #use netkey over klips(old version)
        plutostderrlog=/tmp/pluto.log

conn L2L-IPSEC
        auto=start #automatically start if detected
        type=tunnel #tunnel mode/not transport
       
        ###THIS SIDE###
        left=x.x.137.133
        leftsubnet=172.16.255.1/32
        leftsourceip=172.16.255.1 # this is needed so Openswan knows what IP to source from when packets originate on this side of the tunnel.
       
        ###PEER SIDE###
        right=x.x.157.15
        rightsubnet=192.168.1.0/24

        #phase 1 encryption-integrity-DiffieHellman
        keyexchange=ike
        ike=3des-md5-modp1024,aes256-sha1-modp1024
        ikelifetime=86400s
        authby=secret #use presharedkey
        rekey=yes  #should we rekey when key lifetime is about to expire

        #phase 2 encryption-pfsgroup
        phase2=esp #esp for encryption | ah for authentication only
        phase2alg=3des-md5;modp1024
        pfs=no
        forceencaps=yes

Let’s walk thru this.

config setup

— this is the Global configuration block, logging, and other global defined items here
• listen — sets whcih IP to listen for incoming ESP packets
• plutodebug=none — Debugging, can be helpful for troubleshooting pluto engine. I tend to find the plutostderrlog , below, to be more useful.
• klipsdebug=none — not needed, since we are using netkey which uses pluto.
• plutoopts=”–perpeerlog” — informs pluto to create a individual log per peer.
• nat_traversal=yes — required since we are using RFC1918 addressing (172.16.255.1)
• virtual_private=%v4:172.16.255.1/32,%v4:192.168.0.0/24 — tells Openswan which RFC1918 addresses can traverse the tunnel
• oe=off = Should oppurtunistic encryption be enabled, default is off on Cisco ASA
• protostack=netkey — Use netkey engine, not KLIPS
• plutostderrlog=/tmp/pluto.log — where to dump pluto logs, these are verfy helpful for debugging!!

• auto=start — Tells openswan to start the tunnel if it sees interesting traffic (traffic destined to the other end of the tunnel)
• type=tunnel — Run in Tunnel Mode, not Transport Mode
• left=x.x.137.133 — Defines the Local Peer IP
• leftsubnet=172.16.255.1/32 — Defines the Networks on this side
• leftsourceip=172.16.255.1 — If Openswan is NOT a gateway, need to define a source IP.
• right=x.x.157.15 — Defines the Remote Peer IP
• rightsubnet=192.168.1.0/24 — Defines the Remote network
• keyexchange=ike — Defines IKE as the key exchange method
• ike=3des-md5-modp1024,aes256-sha1-modp1024 — Phase 1 allowed encryption-hash-diffe method. You can list as many as you want by using a comma. Remember the first one that matches is the one used. Use this definition list.
• ikelifetime=86400s = Defines the lifetime of the key, rekeying will happen after this expires.
• authby=secret — Use pre-shared key to authentication Phase 1
• rekey=yes — Yes is default, which is to rekey when key expires
• phase2=esp — Use Encapsulate Security Payload (ESP) in phase 2
• phase2alg=3des-md5;modp1024 — Defines the Phase 2 algorithms to use Encryption-Hash. modp1024 is only used if PFS is enabled. Use this definition list here.
• pfs=no — Pefect Forward Security,
• forceencaps=yes — Required if NAT-Traversal is enabled.

Next, add the preshare key to the ipsec.secrets file.

openswan# vi /etc/ipsec.secrets

#######/etc/ipsec.secrets##############
#{local}    {peer}     : PSK "{secret}"
x.x.137.133 x.x.157.15 : PSK "{secret}"

Cisco ASA side:

First, configure the IKE policy:

crypto ikev1 policy 1
 authentication pre-share
 encryption 3des
 hash md5
 group 2
 lifetime 86400

• crypto ikev1 policy 1 — Defines the IKE policy as version 1 (ikev1), and this is the first policy (policy 1). Keep in mind you can have as many policies as you want, but the ASA will choose the first one that matches with the other side of the tunnel!
• authentication — sets what type of authentication will take place to form the tunnel. This can be a pre-shared key like the one we are using or a SSL certifciate, or even an RSA key
• encryption — sets the encryption algorithm to use when creating the underlying tunnel, check with your hardware vendor because most times the vendor will have hardware support for certain encryi8ption types. Cisco ASA has 3DES hardware support which is why I chose it.
• hash — set the integrity hash algorithm to verify that data hasn’t been altered either by accident or malisiouly.
• group 2 — sets the diff stength when determining the key-exchange-algorithm
• lifetime 86400 — sets the IKE lifetime until Phase 1 will be re negotiated. This usually is a long time since this is the underlying tunnel.

Next configure the Transform Set:

crypto ipsec ikev1 transform-set vps1TS esp-3des esp-md5-hmac

• crypto ipsec ikev1 — IKE version to use for phase 2
• transform-set vps1TS — sets transform-set name
• esp-3des — Encapsulating Security Payload(ESP) encryption algorithm to use to encrypt data and ensure confidentiality.
• esp-md5-hmac — sets the Integrity Hash Authentication Code(HMAC)to use to ensure data integrity.

NOTICE: You can list multiple combinations in this line, it will try to negotiate the first match.

Now, create the Tunnel Group: (make sure you use the same pre-shared key from above!!)

tunnel-group x.x.137.133 type ipsec-l2l
tunnel-group x.x.137.133 ipsec-attributes
 ikev1 pre-shared-key {secret}

Create the ACL

access-list VPN-TRAFFIC-VPS1 extended permit icmp 192.168.1.0 255.255.255.0 host 172.16.255.1 
access-list VPN-TRAFFIC-VPS1 extended permit ip 192.168.1.0 255.255.255.0 host 172.16.255.1 

• access-list VPN-TRAFFIC-VPS1 — give the ACL a unique name
• extended permit — extended ACL type since we will be specficing an IP protocol
• icmp — for pings
• ip — for IP and upper layers
• 192.168.1.0 255.255.255.0 — 192.168.1.0/24 network as source
• host 172.16.255.1 — 172.16.255.1 as destination, if you had more than a single host you would use network netmask notation. 172.16.255.0 255.255.255.0

Tie it all together with the Crypto Map:

crypto map outside-cmap 40 match address VPN-TRAFFIC-VPS1
crypto map outside-cmap 40 set peer x.x.137.133
crypto map outside-cmap 40 set ikev1 transform-set vps1TS
crypto map outside-cmap interface outside

• crypto map outside-cmap 40 — sets the crypto map name (outside-cmap) and number (40), you can have a lot of IPSec peers!!
• set peer x.x.137.133 — assigns Peer IP of remote side
• set ikev1 transform-set vps1TS — sets IKE version to 1 and defines which Transform Set to use
• interface outside — sets the interface to use this collection of Crypto Maps

Troubleshooting

• • ipsec verify — verify ipsec is loading properly.
  • ipsec status –auto — check Openswan attempts to load your configuration file.
  • tail -50f /tmp/pluto.log — very useful information about IKE negotations

Sources:

• • http://linux.die.net/man/5/ipsec.conf
  • http://wiki.strongswan.org/projects/strongswan/wiki/IKEv1CipherSuites
  • http://wiki.strongswan.org/projects/strongswan/wiki/IpsecConf
  • http://ubuntuforums.org/showthread.php?t=1455881
  • http://www.amaranten.com/support/user%20guide/VPN/IPSec_Basics/Overview.htm
  • http://www.unixwiz.net/techtips/iguide-ipsec.html

Tags: CiscoSecurity