Wednesday 28 December 2016

BEST INTERVIEW QUESTIONS HOW VPN WORKS Q5

HOW VPN WORKS

virtual private networking
A VPN (virtual private network) is a private network constructed within a public network infrastructure, such as the global Internet. Businesses can use a VPN to securely connect remote offices and remote users using cost-effective, third-party Internet access, instead of expensive, dedicated WAN links or long-distance remote dial links.
Organizations can use a VPN to reduce WAN bandwidth costs, while increasing connectivity speeds by using high-bandwidth Internet connectivity, such as DSL, Ethernet, or cable.

A VPN provides the highest possible level of security through encrypted IP Security (IPsec) or Secure Sockets Layer (SSL) VPN tunnels and authentication technologies. These protect data traversing the VPN from unauthorized access. Companies can take advantage of the easy-to-provision Internet infrastructure of the VPN to quickly add new sites or users. They can also dramatically increase VPN reach without significantly expanding infrastructure.

A VPN Extends Security for Remote Users
An SSL VPN and an IPsec VPN have become the primary VPN solutions for connecting remote offices, remote users, and business partners, because they:
·         Provide secure communications with access rights tailored to individual users, such as employees, contractors, or partners
·         Enhance productivity by extending corporate network and applications
·         Reduce communications costs and increases flexibility
The two types of encrypted VPNs are:
·         Site-to-Site IPsec VPN: This alternative to Frame Relay or leased-line WANs allows businesses to extend network resources to branch offices, home offices, and business partner sites.
·         Remote-Access VPN: This extends almost any data, voice, or video application to the remote desktop, emulating the main office desktop. A remote-access VPN may be deployed using SSL VPN, IPsec or both, depending on deployment requirements.

What VPN can do??

  • Encryption scrambles data crossing the link;
  • Authentication of incoming information to assure that it has not been tampered with or corrupted, and comes from a legitimate source;
  • Access control verifying the identity of the person or network address requesting network entry.
The result is a secure 'tunnel' of information flow which utilizes the Internet but is not accessible to anyone outside your network. When an authorized user logs off, the tunnel between them and the network disappears.


VPN provides the highest possible level of security through encrypted IP Security (IPsec) 

IPSEC

Internet Protocol Security (IPsec) is a technology protocol suite for securing Internet Protocol (IP) communications by authenticating and/or encrypting each IP packet of a communication session. IPsec also includes protocols for establishing mutual authentication between agents at the beginning of the session and negotiation of cryptographic keys to be used during the session.(source WiKi)


Modes of IPSec VPN

Tunnel and Transport Modes

IPSec can be run in either tunnel mode or transport mode. Each of these modes has its own particular uses and care should be taken to ensure that the correct one is selected for the solution:
  • Tunnel mode is most commonly used between gateways, or at an end-station to a gateway, the gateway acting as a proxy for the hosts behind it.
  • Transport mode is used between end-stations or between an end-station and a gateway, if the gateway is being treated as a host—for example, an encrypted Telnet session from a workstation to a router, in which the router is the actual destination.


Phases of IPSec VPN


so you can see that IPSec VPN tunnels Uses IKE Phase1 and Phase2 for tunnel creation. Different types
of security measures used in this phases are listed below.


In symmetric cryptographic systems, both communicating parties use the same key for encryption and decryption. The material used to build these keys must be exchanged in a secure fashion. Information can be securely exchanged only if the key belongs exclusively to the communicating parties.
The goal of the Internet Key Exchange (IKE) is for both sides to independently produce the same symmetrical key. This key then encrypts and decrypts the regular IP packets used in the bulk transfer of data between VPN peers. IKE builds the VPN tunnel by authenticating both sides and reaching an agreement on methods of encryption and integrity. The outcome of an IKE negotiation is a Security Association (SA).
This agreement upon keys and methods of encryption must also be performed securely. For this reason IKE, is composed of two phases. The first phase lays the foundations for the second
Diffie-Hellman (DH) is that part of the IKE protocol used for exchanging the material from which the symmetrical keys are built. The Diffie-Hellman algorithm builds an encryption key known as a "shared secret" from the private key of one party and the public key of the other. Since the IPSec symmetrical keys are derived from this DH key shared between the peers, at no point are symmetric keys actually exchanged.
Methods of Encryption and Integrity
Two parameters are decided during the negotiation:
o        Encryption algorithm
o        Hash algorithm
Methods of Encryption/integrity for IKE
Parameter
IKE Phase 1 (IKE SA)
IKE PHASE 2 (IPSec SA)
Encryption
§     AES -256(default)
§     3DES
§     DES
§     CAST
§     AES -128 (default)
§     3DES
§     AES - 256
§     DES
§     CAST
§     DES -40CP
§     CAST -40
§     NULL
§     AES-GCM -128
§     AES-GCM -256
Integrity
§     SHA1 (default)
§     MD5
§     SHA -256
§     AES-XCBC
§     SHA -384
§     MD5 (default)
§     SHA1
§     SHA -256
§     AES-XCBC
§     SHA -384
NULL means perform an integrity check only; packets are not encrypted.

Diffie Hellman Groups
The Diffie-Hellman key computation (also known as exponential key agreement) is based on the Diffie Hellman (DH) mathematical groups. A Security Gateway supports these DH groups during the two phases of IKE.
DH groups
Parameter
IKE Phase 1 (IKE SA)
IKE Phase 2 (IPSec SA)
Diffie Hellman Groups
§     Group2 (1024 bits) (default)
§     Group1 (768 bits)
§     Group5 (1536 bits)
§     Group14 (2048 bits)
§     Group19 (256-bit ECP)
§     Group20 (384-bit ECP)
§     Group2 (1024 bits) (default)
§     Group1 (768 bits)
§     Group5 (1536 bits)
§     Group14 (2048 bits)
§     Group19 (256-bit ECP)
§     Group20 (384-bit ECP)
A group with more bits ensures a key that is harder to break, but carries a heavy cost in terms of performance, since the computation requires more CPU cycles.


IKE Phase I
During IKE Phase I:
o        The peers authenticate, either by certificates or via a pre-shared secret. (More authentication methods are available when one of the peers is a remote access client.)
o        A Diffie-Hellman key is created. The nature of the Diffie-Hellman protocol means that both sides can independently create the shared secret, a key which is known only to the peers.
o        Key material (random bits and other mathematical data) as well as an agreement on methods for IKE phase II are exchanged between the peers.
In terms of performance, the generation of the Diffie Hellman Key is slow and heavy. The outcome of this phase is the IKE SA, an agreement on keys and methods for IKE phase II. Figure below  illustrates the process that takes place during IKE phase I but does not necessarily reflect the actual order of events.

             
 
IKE Phase II (Quick mode or IPSec Phase)
IKE phase II is encrypted according to the keys and methods agreed upon in IKE phase I. The key material exchanged during IKE phase II is used for building the IPSec keys. The outcome of phase II is the IPSec Security Association. The IPSec SA is an agreement on keys and methods for IPSec, thus IPSec takes place according to the keys and methods agreed upon in IKE phase II.
We are using ESP or AH on Phase II so , let us take a look on both.

Let us took an example on the protocol perspective.



Once the IPSec keys are created, bulk data transfer takes place, between two endpoints:



SITE TO SITE VPN LAB :


Use the same security policy on R1 Side as it is in R2 side, in the reverse direction.
R2#sh ip int brief | ex unassi
Interface                  IP-Address      OK? Method Status                Protocol
Serial1/0                  64.1.1.2        YES manual up                    up
Serial1/1                  200.1.1.2       YES manual up                    up
R2#sh ip route rip
     1.0.0.0/32 is subnetted, 2 subnets
R       1.1.1.1 [120/1] via 64.1.1.1, 00:00:13, Serial1/0
R       1.1.1.2 [120/1] via 64.1.1.1, 00:00:13, Serial1/0
     2.0.0.0/32 is subnetted, 2 subnets
R       2.2.2.2 [120/1] via 200.1.1.1, 00:00:13, Serial1/1
R       2.2.2.1 [120/1] via 200.1.1.1, 00:00:13, Serial1/1



R3#sh run | se crypto|access-list|ipsec
crypto isakmp policy 10
 encr aes
 hash md5
 authentication pre-share
 group 2
crypto isakmp key cisco address 64.1.1.1 255.255.255.252
crypto ipsec transform-set TSET esp-aes esp-md5-hmac
crypto map VPNMAP 1212 ipsec-isakmp
 set peer 64.1.1.1
 set transform-set TSET
 match address VPNTRAFFIC
 crypto map VPNMAP
ip access-list extended VPNTRAFFIC
 permit ip 2.2.2.0 0.0.0.3 1.1.1.0 0.0.0.3


R3#sh crypto ipsec sa

interface: Serial1/1
    Crypto map tag: VPNMAP, local addr 200.1.1.1

   protected vrf: (none)
   local  ident (addr/mask/prot/port): (2.2.2.0/255.255.255.252/0/0)
   remote ident (addr/mask/prot/port): (1.1.1.0/255.255.255.252/0/0)
   current_peer 64.1.1.1 port 500
     PERMIT, flags={origin_is_acl,}
    #pkts encaps: 1, #pkts encrypt: 1, #pkts digest: 1
    #pkts decaps: 1, #pkts decrypt: 1, #pkts verify: 1
    #pkts compressed: 0, #pkts decompressed: 0
    #pkts not compressed: 0, #pkts compr. failed: 0
    #pkts not decompressed: 0, #pkts decompress failed: 0
    #send errors 0, #recv errors 0

     local crypto endpt.: 200.1.1.1, remote crypto endpt.: 64.1.1.1
     path mtu 1500, ip mtu 1500, ip mtu idb Serial1/1
     current outbound spi: 0x291E298F(689842575)

     inbound esp sas:
      spi: 0x34258C8C(874876044)
        transform: esp-aes esp-md5-hmac ,
        in use settings ={Tunnel, }
        conn id: 2001, flow_id: SW:1, crypto map: VPNMAP
        sa timing: remaining key lifetime (k/sec): (4558322/2613)
        IV size: 16 bytes
        replay detection support: Y
        Status: ACTIVE

     inbound ah sas:

     inbound pcp sas:

     outbound esp sas:
      spi: 0x291E298F(689842575)
        transform: esp-aes esp-md5-hmac ,
        in use settings ={Tunnel, }
        conn id: 2002, flow_id: SW:2, crypto map: VPNMAP
        sa timing: remaining key lifetime (k/sec): (4558322/2611)
        IV size: 16 bytes
        replay detection support: Y
        Status: ACTIVE

     outbound ah sas:

     outbound pcp sas:
R3#sh crypt is
R3#sh crypt isakmp sa
dst             src             state          conn-id slot status
200.1.1.1       64.1.1.1        QM_IDLE              1    0 ACTIVE

No comments:

Post a Comment