What is an IPsec Site-to-Site VPN?

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 IP packet with header information is encapsulated and encrypted, in Transport mode only the TCP/UDP payload is encrypted.
http://www.amaranten.com/support/user%20guide/image146.gif from amaranten.com.

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.

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

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.

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:

Needed for Debian:

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.

Cisco ASA side:

First, configure the IKE policy:

  • 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 — 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!!)

Create the ACL

  • 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 — 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:

There are 8 comments left Go To Comment

  1. Bob /

    You have a typo: sysbtl.conf = sysctl.conf

    Also, you should consider using libreswan and not openswan.

    also why are you using 3des?, aes is more secure, and most new cpus and hw devices, have hardware acceleration for aes.

    1. Jim / Post Author

      Thank you Bob, I’ve correct the typo. As for 3DES, I think I used that because of another project I was working on where the the hardware I was using (Cisco 1711, I know very old), only support 3DES hardware acceleration. As you’ve stated AES is more preferred now-a-days. Cheers!

  2. Gianluca /

    Thank you. Saved my life

  3. Pingback: Easy Remote Client VPN Solution with a Cisco ASA | thejimmahknows /

  4. jonatan /

    HI,

    i have a question. In the listen what ip should be? The public IP of the openswan machine, and in the “left” what ip is?

    I can see taht you put x.x.137.134 and x.x.x137.33 and I get confused.

    thanks.

    1. Jim / Post Author

      Left refers to “this” side of the tunnel, the openswan side. x.x.137.133 is the correct address. I’ve corrected the article. Thank you!

  5. jonatan /

    Thanks Jim, another question,
    Shouldn I add a no Nat access list so the traffic to the vpn tunnel do not pass through NAT?

    1. Jim / Post Author

      It depends on your security device. I know for Cisco ASA devices,NAT’ing takes place first and NAT statement is only required when traversing different security-levels (these are set up for each interface). Other devices that require the no-NAT do so to identify traffic destined out an interface or pool set up for PAT’ing. For example if your device doesn’t do PATs for egressing traffic, you wouldn’t need a no-NAT. However you would still need for both cases an access-list or something similar to identify the traffic to put inside the tunnel. I usually call this the “Interesting traffic ACL”
      Back to openswan, the section “rightsubnet=192.168.1.0/24” and “leftsubnet=172.16.255.1/32” identifies the “Interesting traffic ACL” for Openswan to put inside the tunnel.

Leave a Reply