{"id":796,"date":"2014-04-10T18:36:12","date_gmt":"2014-04-10T22:36:12","guid":{"rendered":"https:\/\/infotechguy.net\/?p=796"},"modified":"2022-08-26T09:49:35","modified_gmt":"2022-08-26T13:49:35","slug":"site-to-site-ipsec-vpn-using-openswan-and-cisco-asa-9-13","status":"publish","type":"post","link":"https:\/\/infotechguy.net\/?p=796","title":{"rendered":"What the IPSEC are you talking about?"},"content":{"rendered":"

What is IPsec?<\/h2>\n

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<\/a>. 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<\/em> communication, network-to-network<\/em> communication, host-to-network<\/em>. The most common type is network-to-network<\/em>. An argument can be made that host-to-host<\/em> is the same as network-to-network<\/em> with \/32s (i.e. 192.168.1.1\/32 to 192.168.255.1\/32). Anyway!<\/p>\n

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<\/strong> with 192.168.1.0\/24 <\/em>address space and CompanyB<\/strong> with 172.16.1.0\/24<\/em> 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<\/strong> would be able to traverse the IPsec tunnel to CompanyB<\/strong> 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!!<\/p>\n

Phase 1 and Phase 2 ???<\/h4>\n

“Phase 1”<\/strong> — Before IPsec<\/strong> 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)<\/strong>, which consists of (I think) 3 different Key Management protocols. ISAKMP<\/a>, Oakley<\/a>, SKEME. All of which are used based on how you want to setup the key exchange, ISAKMP<\/strong> being the most popular. The main point of this Phase 1<\/strong> 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<\/strong>. Once both of those have been completed we have a successfully formed a IKE Security Association(SA)<\/strong> that maintains this trust. IKE<\/strong> uses the key exchange algorithm called Diffie-Hellman<\/a> 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 SA<\/strong>s, creatively called “Phase 2”. Keep in mind thata single Phase 1 SA<\/strong> can house multiple IPSec SA<\/strong>s!!!, unless you are using Perfect Forward Security(PFS)<\/strong>. PFS<\/strong> 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? \ud83d\ude42<\/p>\n

“Phase 2”<\/strong> — IKE<\/strong> is used to negotiate IPSec SAs<\/strong> and how IPSec<\/strong> should be protected. In this Security Association (SA)<\/strong>, the actual networks at each end of the tunnel must be agree upon. If they are not, Phase 2<\/strong> will never come up as their SA<\/strong> are in mismatch. Furthermore, in this Phase 2<\/strong> an agree upon Transform-set<\/strong> is established. The Transform-Set<\/strong> 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?<\/em> Phase 2<\/strong> also uses the key exchanged from Phase 1<\/strong> to be used when encrypting the data. If PFS<\/strong> is used, keys are derived independently and not from Phase 1<\/strong>. The cost being time, benefit being a single key compromise does not compromise all IPSec tunnels. Keep in mind Phase 2<\/strong> is required to be completed at both ends. If not the opposing side won’t know how to decrypt the data!!<\/p>\n

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<\/a>. Also if you haven’t already bookmark PacketLife.net<\/a>!!<\/p>\n

Tunnel vs Transport ??<\/h4>\n

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.
\n\"\"<\/a>
\n***Source– https:\/\/www.slideshare.net\/keshabnath\/ip-security-19425154***<\/a><\/p>\n

The Design:<\/h3>\n

\"\"
\nOpenswan 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.
\n<\/p>\n

Network info:<\/h4>\n

Openswan<\/strong> 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.<\/p>\n

\nroot@vps1:\/# ifconfig lo:1\nlo:1      Link encap:Local Loopback\n          inet addr:172.16.255.1  Mask:255.255.255.255\n          UP LOOPBACK RUNNING  MTU:16436  Metric:1\n<\/pre>\n
Or..edit your \/etc\/network\/interfaces<\/strong> config file.<\/p>\n
auto lo:1\n        iface lo:1 inet static\n        address 172.16.255.1\n        netmask 255.255.255.255\n<\/pre>\n
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.<\/p>\n
Cisco ASA <\/strong>is authoritative for 192.168.1.0\/24, which is a single \/24 network behind the Firewall.<\/p>\n
asa# show ip\nSystem IP Addresses:\nInterface                Name                   IP address      Subnet mask     Method\nVlan1                    inside                 192.168.1.1     255.255.255.0   CONFIG\n<\/pre>\n
Phase 1 Parameters:<\/strong>
\nEncryption = 3DES<\/em>
\nIntegrity Hash = MD5
\nDiffie\u2013Hellman = Group 2 (1024-bit)
\nIKE lifetime = 86400s<\/em><\/p>\n
Phase 2 Parameters:<\/strong>
\nEncryption = ESP-3DES
\nIntegrity Hash = ESP-MD5<\/em><\/p>\n
Configuration Time!<\/h3>\n
OpenSwan Side:<\/h4>\n
root@vps1:~# apt-get install openswan ntp ike-scan ipsec-tools\nroot@vps1:~# mv \/etc\/ipsec.conf \/etc\/ipsec.conf.bak\nroot@vps1:~# vi \/etc\/ipsec.conf\n<\/pre>\n
Needed for Debian:<\/p>\n
echo \"net.ipv4.ip_forward=1\" >> \/etc\/sysctl.conf\necho \"net.ipv4.conf.all.send_redirects=0\" >> \/etc\/sysctl.conf\necho \"net.ipv4.conf.all.accept_redirects = 0\" >> \/etc\/sysctl.conf\n<\/pre>\n
######\/etc\/ipsec.conf#######\nconfig setup\n        listen=x.x.137.133\n        plutodebug=none\n        klipsdebug=none\n        plutoopts=\"--perpeerlog\"\n        \n        nat_traversal=yes\n        virtual_private=%v4:172.16.255.1\/32,%v4:192.168.0.0\/24\n        oe=off #opportunistic encryption is off\n        protostack=netkey #use netkey over klips(old version)\n        plutostderrlog=\/tmp\/pluto.log\n\nconn L2L-IPSEC\n        auto=start #automatically start if detected\n        type=tunnel #tunnel mode\/not transport\n       \n        ###THIS SIDE###\n        left=x.x.137.133\n        leftsubnet=172.16.255.1\/32\n        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.\n       \n        ###PEER SIDE###\n        right=x.x.157.15\n        rightsubnet=192.168.1.0\/24\n\n        #phase 1 encryption-integrity-DiffieHellman\n        keyexchange=ike\n        ike=3des-md5-modp1024,aes256-sha1-modp1024\n        ikelifetime=86400s\n        authby=secret #use presharedkey\n        rekey=yes  #should we rekey when key lifetime is about to expire\n\n        #phase 2 encryption-pfsgroup\n        phase2=esp #esp for encryption | ah for authentication only\n        phase2alg=3des-md5;modp1024\n        pfs=no\n        forceencaps=yes\n<\/pre>\n
Let’s walk thru this.<\/p>\n
config setup <\/strong><\/p>\n