VPN tunnel with deployed IPSec is the best solution in a view of low cost for small companies with at most a few branches. If you can’t afford to deploy VPLS (Virtual Private Lan Service) due to the budget or lack of MPLS infrastructure, VPN and IPSec will come forward to you. Low cost, simplicity (after all), and security. IPSec over VPN tunnel – what exactly hides behind these acronym?
Let’s assume below situiation. Two branches, two ASA (firewalls) at the edge of each branch , two networks (10.0.1.0/24 and 10.0.2.0/24), host from one network tries to communicate securely with an e-mail server which is placed in the second branch (network). In order to do this I am going to deploy IPSec site-to-site VPN connection…
VPN (Virtual Private Networks) is used in order to create the tunnel between two nodes (routers, clients), which is used to create a private network and allows to flow a traffic seamlessly between these two nodes. Whole traffic is sent through the public, unsecure network (like the Internet).
Establishing secure IPSec VPN (IKEv1) tunnel consists of 2 Phases :
1) ISAKMP Security Association setup
2) IPSec Security Association negotiation
Phase 1 tunnel is called “management tunnel” and has nothing to do with data encryption. During this phase two nodes establish the tunnel which will be subjected to encryption. Negotiated parameters are sent with using UDP port 500. Phase 1 ISAKMP can works in 2 modes: main mode (6 messages need to be exchanged) and aggressive mode (requires only 3 messages), necessary information is squeezed and consists of a few steps according to the HAGLE process:
HASH – necessary if we want to make sure that data integrity has been retained and data haven’t been modified. Examples of HASH algorithm are MD5, SHA1, SHA2. HMAC – provides common key during HASH calculation, examples : HMAC-MD5.
AUTHENTICATION – with Preshared Key (PSK) , Public Key Infrastructure ( Certification Authority) and RSA algorithm (public/private key). Uses in order to authenticate 2 hosts in insecure network.
GROUP (Diffie-Hellman) – DH algorithm is used in order to generate “shared secret” thanks to Public/Private Keys generated by 2 sites. Firstly the keypair Private/Public is generated on each site. Public key is being sent to the Receiver. Private key is always stored by Sender. The “Shared Key” is generated by using Public Key of the second site, own Private Key and Diffie Hellman algorithm. Private key encrypts the HASH and in this way we get Digital Signature, which may be decrypted only with Public Key of the Sender which Receiver got already.
Calculation of the Shared Secret looks in this way, of course I simplified the process with subsitution of simple numbers, the whole process is much more complicated, but it shows how Private and Public keys are involved
LIFETIME – how long session will be lasting, before Security Associations expire and the new one will have to be negotiated.
ENCRYPTION – symmetric – we have one shared key, algorithm examples are DES, AES, 3DES
After these steps, management tunnel is established and negotiations may go over Phase 2.
While phase 1 is responsible for management, establishing tunnel and negotiation its conditions, phase 2 is responsible for delivering security. During phase 2 transform-set has to be deployed. Ends of the tunnel are trying to match theirs “transform-sets” (proposals ). Two crucial things have to take place :
ENCRYPTION ( eg. esp-aes, esp-3des)
HASH (eg. esp-sha-hmac)
Lifetime and DH Group are not necessary.
We may set up a new diffie-hellman group and choose Perfect Forward Secrecy which ensures us that any exists key material will not be used again and new key material will be generated every time during DH exchange.
Security Protocols which are used during IPSec negotiations :
ESP – Encapsulating Security Payload , protocol number 50, provides encryption, integrity and authentication.
AH – Authentication Header, protocol number 51, provides integrity and authentication only ! Not in use anymore!
Modes which are used during IPSEC negotiations :
TUNNEL – (default mode for any IPSEC) This mode is used in site to site connection (or Remote Access), traffic behind edge routers on both sites is not encrypted, only traffic that leaves outside interfaces. In this mode DATA + ORIGINAL IP HEADER + ESP HEADER are AUTHENTICATED and DATA+ORIGINAL IP HEADER are ENCRYPTED. So entire protection of our packet looks in this way:
TRANSPORT – This mode is used in host to host protection, but you may also find this type of tunnel in GETVPN that encapsulates the packet and preserves the IP address of the outside interface and IPSec protects its. In this mode DATA+ESP HEADER are AUTHENTICATED and only DATA is ENCRYPTED. So entire protection of our packet looks in this way:
NAT Traversal – One of the most important invention in IPSec is NAT-T. Thanks to this solution we don’t have to worry about PAT (Port Address Translation). Why we should worry at all ? ESP uses SPI (Security Parameter Index) instead of TCP ports on layer 4, which actually do very similar job,SPI is added to the IP address alike TCP port number, so if packet comes across on its path the router with PAT service , PAT will not work, because there are no visible ports to translation (TCP ports are hidden behind original IP header and everything behind ESP header is encrypted). NAT Traversal provides UDP encapsulation on ports 4500 (In both direction as SRC and DST ports) thanks to this our packet will be looking in this way (in tunnel mode) and port translation will be possible :
How IPSec is implemented ?
In order to implement IPSec, Crypto ACL are used to mark the traffic that we are going to protect (Interesting Traffic). Crypto ACL is a different type then standard and extended ACL. Thanks to this you may use one physical router port. Some traffic (destined to the second branch) will be going through IPSec VPN and the other traffic (destined to the Internet) will be going through non secured connection. Our Crypto ACL looks in this way :
Crypto ACL ————>source———>destination
Crypto ACL site 1 ——> 10.0.1.0/24——>10.0.2.0/24
10.0.1.0/24 <——10.0.2.0/24<——-CRYPTO ACL site 2