Vpn.docx

  • Uploaded by: Madhu Thamatam
  • 0
  • 0
  • December 2019
  • PDF

This document was uploaded by user and they confirmed that they have the permission to share it. If you are author or own the copyright of this book, please report to us by using this DMCA report form. Report DMCA


Overview

Download & View Vpn.docx as PDF for free.

More details

  • Words: 2,449
  • Pages: 8
IPsec Concepts, Components, and Operations IPsec has four fundamental goals: + ConfidentialityEncryption + Data integrityHashing + Peer authenticationPre-shared keys (PSK), RSA digital signatures + Antireplay Integrated into IPsec, basically applying serial numbers to packets

IPSec uses the following protocols: Internet Key Exchange(IKE) Encapsulating Security Payload (ESP) Authentication Header (AH)

Internet Key Exchange 1. Main Mode 2. Aggressive Mode 3. Quick Mode IKE is the protocol used to setup security association between IPSec peers. It provides a framework to exchange the security parameters & policies between them. These security policies must be manually defined at peers. It has the following modes: 1. Main Mode 2. Aggressive Mode 3. Quick Mode Main Mode In this 6 messages are exchanged in three steps as follows: Step1 – Proposal Exchange Message 1-initiator will send own proposal to responder Message 2-responder will send own proposal to initiator Step2 – Key Exchange Message 3-initiator will send own key to responder Message 4-responder will send own key to initiator Step3 – Session Authentication Message 5-initiator will authenticate the session Message 6-responder will authenticate the session Aggressive Mode In this 6 messages are converted into three. The messages sent are as mentioned below: 1. Initiator will send own proposal & key to responder. 2. Responder will authenticate initiator's proposal. It also sends own proposal & key to initiator. 3. Initiator will authenticate the session. Quick Mode

In quick mode they will recheck their attributes using SPI (Security Parameter Index). SPI is sent with every packet by peers. IKE Phases IKE has the following phases: 1. Phase1 2. Phase1.5 (optional) 3. Phase2 IKE Phase 1 In Phase1 they create a single IKE bi-direction tunnel. Single key is used to authenticate the session. Mode used depends on IPSec VPN. IKE Phase 1.5 It is an optional IKE phase. Phase 1.5 provides an additional layer of Authentication called Xauth (Extended Authentication). Xauth forces the user to authenticate before use Of the IPSec connection. IKE Phase 2 When phase1 is successfully completed Phase2 is initiated. If phase1 isn’t complete Phase2 will never start. In phase2 they create multiple IPSec unidirectional tunnels. Two tunnels are created per protocol ESP (Encapsulating Security Payload) or AH (Authentication Header). Internet Security Association Key Management Protocol (ISAKMP ) IKE is a management protocol which uses ISAKMP for key and attributes exchange. ISAKMP uses UDP Port 500.

IPSec Modes IPSec has the following modes: 1. Transport mode 2. Tunnel mode Transport Mode: - It protects layer4 & upper layer data. It is used in DMVPN. Tunnel Mode: - It protects layer3 & upper layer data. It is used in Site-Site, Remote-Access and GETVPN.

NAT-Traversal It is a feature which enables us to establish VPN session through NAT device. In NAT-T VPN devices add UDP header before ESP header, so that NAT device can perform NAT with packet.

The Internet Key Exchange (IKE) Protocol IPsec uses the Internet Key Exchange (IKE) protocol to negotiate and establish secured site-tosite or remote access virtual private network (VPN) tunnels.In IKE Phase 1 IPsec peers negotiate and authenticate each other. In Phase 2 they negotiate keying materials and algorithms for the encryption of the data being transferred over the IPsec tunnel. + IKEv2 enhances the function of performing dynamic key exchange and peer authentication.

+ Both IKEv1 and IKEv2 protocols operate in two phases. IKEv2 provides a simpler and more efficient exchange. Phase 1 in IKEv2 is IKE_SA, consisting of the message pair IKE_SA_INIT (IKEv1 Phase 1). Phase 2 in IKEv2 is CHILD_SA is the IKE_AUTH message pair (IKEv1 Phase 2). The Play by Play for IPsec Step 1: Negotiate the IKEv1 Phase 1 Tunnel This tunnel (once established) is not going to be used to forward user packets, but rather only to protect management traffic related to the VPN between the two routers. Five basic items need to be agreed upon between the two VPN devices/gateways (in this case, the two routers) for the IKE Phase 1 tunnel to succeed, as follows: + Hash algorithm, MD5 or SHA + Encryption algorithm, DES (weak), 3DES (better) or AES (best) +Diffie-Hellman (DH) group to use; The DH “group” refers to the modulus size (length of the key). The purpose of DH is to generate shared secret keying material (symmetric keys) that may be used by the two VPN peers for symmetrical algorithms, such as AES. + Authentication method: PSK or RSA signatures + Lifetime: How long until this IKE Phase 1 tunnel should be torn down. Step 2: Run the DH Key Exchange DH allows two devices that do not yet have a secure connection to establish shared secret keying material (keys that can be used with symmetrical algorithms, such as AES). Step 3: Authenticate the Peer The last piece of IKE Phase 1 is to validate or authenticate the peer on the other side. IKE Phase 1 tunnel, this tunnel is used only as a management tunnel so that the two routers can securely communicate with each other directly.IKE Phase 1 tunnel is not used to encrypt or protect the end user’s packets.The IKE Phase 2 tunnel includes the hashing and encryption algorithms. So, we could say we have one IKE Phase 1 bidirectionaltunnel used for management between the two VPN peers and two IKE Phase 2 unidirectional tunnels used for encrypting and decrypting end-user packets. Security Association It is a group of security parameters and policies which is agreed between two IPSec peers. Security Association Components are Security Association Database (SAD) and Security Policy Database (SPD) Diffie-Hellman Key DH allows the two parties to share a secret key over an insecure channel. Because this key forms the basis of the rest of the VPN, it is essential that the key is kept secret.

Security Parameter Index Both Devices create a hash of Security Policy Database. This hash is called SPI.

Configuring and Verifying IPsec The first thing to plan is what protocols to use for IKE Phase 1 and IKE Phase 2 and to identify which traffic should be encrypted. show crypto isakmp policy = Verify the IKE Phase 1 policies in place on the route show crypto map = the details of the crypto map show crypto isakmpsa[detail] = the details for the IKE Phase 1 tunnel that is in place show crypto ipsecsa = the details for the IKE Phase 2 tunnels that are in place show crypto engine connections active = seeing that the encryption and decryption is working IPsec Site-to-Site VPN IPsec uses two methods for encryption: tunnel and transport mode. If IPsec tunnel mode is used, the IP header and the payload are encrypted. When transport mode is used, only the packet payload is encrypted. Protocols That May Be Required for IPsec: + UDP port 500 (IKEv1 Phase 1) + UDP port 4500NAT-T (NAT Traversal) +Layer 4 Protocol 50ESP + Layer 4 protocol 51 AH Planning IKEv1 Phase 1 Best (ex): + Hashing: SHA + Authentication: RSA-Sigs (which require PKI to be used) + DH group: 5 + Lifetime: 3600 seconds + Encryption: AES-256 Planning IKEv1 Phase 2 Things to set (ex): + VPN Peer global IP addresses + Traffic to protect: Bidirectional traffic between network) + Encryption: AES-192 (just to mix it up a bit, default for AES is 128) + HMAC: SHA + Lifetime: Default + Outside interfaces of routers: G1/0 (on both + PFS: Group 2

Troubleshooting IPsec Site-to-Site VPNs in Cisco IOS show crypto isakmp policy = to verify the configuration show crypto map debug crypto isakmp show crypto isakmpsa = IPSec Phase 1 show crypto ipsecsa = IPSec Phase 2 We want to see a state of QM_IDLE, meaning the IKEv1 Phase 1 is up. show crypto engine connections active . FlexVPN is a unified VPN solution that can be deployed over either public Internet connections or a private Multiprotocol Label Switching (MPLS) VPN network. Functions and Use of SSL for VPNs Clientless SSL VPN feature excels when connections to only one or a few servers are needed and the full-tunneled Cisco AnyConnect Secure Mobility Client cannot be installed on the local computer. SSL and TLS Protocol Framework TLS and its predecessor SSL are cryptographic protocols that provide secure transactions on the Internet for things such as e-mail, web browsing, instant messaging, and so on.SSL as a protocol was originally developed by Netscape.Both of these protocols provide confidentiality, integrity, and authentication services. Similar to IPsec, these protocols use symmetric algorithms for bulk encryption, and asymmetric algorithms are used for the authentication and for the exchange of keys. Cisco SSL VPNs are really using TLS behind the scenes. The Play by Play of SSL for VPNs + The client initiates a connection to the server on port 443 and uses internally a port > 1023 + There is the standard three-way handshake + The server responds, providing its digital certificate, which contains the server’s public key + Validate certificate information + Client sends a shared secret to the server encrypting the key with the server’s public key + Server decrypts the shared secret using its private key + The key is now used to encrypt data over SSL Split Tunneling Without split tunneling, all IP traffic leaving the client’s machine goes through the tunnel to the ASA. A split tunnel addresses this issue by sending traffic down the VPN only if it is destined for specific networks located at the headquarter site.

Troubleshooting SSL Negotiations + Step 1. Verify that the user’s computer can ping the Cisco ASA’s outside IP address + Step 2. If the user’s workstation can ping the address, issue the show running all | include ssl command on the Cisco ASA and verify that SSL encryption is configured. + Step 3. If SSL encryption is properly configured, use an external sniffer to verify whether the TCP three-way handshake is successful AnyConnect clients will fail to establish connection if the Cisco ASAs are configured to accept connection with SSL Server Version 3. You must use TLSv1 for AnyConnect clients. Navigate to Configuration >Remote Access VPN > Advanced > SSL Settings to specify the SSL encryption type and version that you want to use. SSL Features 1. Confidentiality i. Using Encryption algorithms like, Triple Data Encryption Standard (3DES) and Advance Encryption Standard (AES ) 2. Integrity i. Using Hash algorithms like, Message Digest 5 (MD5) and Secure Hash Algorithm (SHA). 3. Data Origin Authentication i. Using Username, Passwords and RSA

SSL Modes It has the following modes: 1. Clientless Mode 2. Thin Client Mode 3. Thick Client Mode

Clientless Mode

As the name suggest in clientless mode there is no need of any client software. In this client makes a request to SSL gateway, which acts as a proxy and sends it to internal resources. Clientless provides secure communication only of web based applications like HTTP, HTTPS and MS exchange Server etc.

Thin Client Mode Since clientless provides secure communication only for web based applications, thin Client was designed for non web based applications. The process remains exactly same as clientless. The only difference is it can only be used for applications which have static TCP ports like Telnet, SSH, RDP etc. It is also known as Port-Forwarding.

Thick Client Mode Thick client mode provides us network layer access like IPSec Remote access VPN. Using this we can access all web based or non web based applications. When client initiates a request to server, a

package gets pushed to client, client installs this package. After package installation server pushes policies to client, these policies include IP address, mask, interesting traffic etc.

SSL Working

1. Client will initiate a request to server 2. Server will provide a certificate to client containing public key of server. 3. Client generates a shared secret key which is encrypted by public key of server. 4. Encrypted shared secret is delivered to server. Server decrypts it using its private key. 5. Now both have same secret, bulk encryption will happen.

DMVPN is used when we want to implement secure fully mesh connectivity among multiple branches over internet in a scalable way.

DMVPNis a Cisco solution for deploying highly scalable IPsec site-to-site VPNs. It enables branch locations to communicate directly with each other over the Internet without requiring a permanent VPN connection between sites DMVPN Terminologies 1. Next Hop Resolution Protocol (NHRP) 2. Multipoint Generic Routing Encapsulation (mGRE) Multipoint GRE mGRE is a layer 3 protocol. It has capabilities to support multiple IPSec tunnels on a single interface. It adds 28 bytes header as compared to GRE which adds 24 bytes header. DMVPN Phases 1. DMVPN Phase 1 2. DMVPN Phase 2 3. DMVPN Phase 3 When we deploy DMPVN with Phase 1, client will boot up and it will register itself with the server. A permanent tunnel is created between hub and spoke. When one spoke wants to communicate with another spoke entire traffic goes through hub. Dynamic tunnel is not created between spokes.

DMVPN Phase 2 When we deploy DMPVN with Phase 2, client will boot up and it will register itself with the server. A permanent tunnel is created between hub and spoke. When one spoke wants to communicate with another spoke a dynamic tunnel is created between spokes DMVPN Phase 3 In DMVPN Phase 3 Cisco added some commands to improve the NHRP query response. These commands are: ip nhrp redirect which is implemented on hub ip nhrp shortcut which is implemented on spokes. When we deploy DMPVN with Phase 3, client will boot up and it will register itself with the server. A

permanent tunnel is created between hub and spoke. When one spoke wants to communicate with another spoke a dynamic tunnel is created between spokes. Due to the extra commands mentioned above when a spoke will do query for a NBMA address to hub. Hub will not give response of this query, hub will redirect the query to that spoke for whom query is generated. Flex VPN Internet Key Exchange Version (IKEv2) is a next-generation key management protocol. It is an enhancement of the IKE Protocol. IKEv2 is used for establishing and maintaining security associations. Flex VPN is Cisco's implementation of IKEv2. It combines site to site, remote access, hub and spoke VPN topologies. Improvements with IKEv2 Dead Peer Detection and Network Address Translation-Traversal: Internet Key Exchange Version 1 (IKEv1) provides NAT-Traversal, but Internet Key Exchange Version 2 (IKEv2) has built-in support for Dead Peer Detection (DPD) and Network Address TranslationTraversal (NAT-T). Denial of Service Attack Resilience: IKEv2 use cookies, to give protection from Denial of Service (DoS) attack. This feature was not in IKEv1, which can be spoofed into performing substantial cryptographic processing from false locations. EAP Support: IKEv2 allows the use of Extensible Authentication Protocol (EAP) for authentication

More Documents from "Madhu Thamatam"

Vpn.docx
December 2019 8
Brksec-2028.pdf
December 2019 9
295.pptx
December 2019 17
Project Document.svce.docx
November 2019 33
Seminar Doc Iv.docx
November 2019 31