CCNAS InstructorPPT Ch8 Short

Chapter 8:
Implementing Virtual
Private Networks
CCNA Security
Presentation_ID 2008 Cisco Systems, Inc. All rights reserved. Cisco Confidential 1
Chapter 8: Objectives
In this chapter you will:
Describe VPNs and their benefits.
Describe VPNs and their benefits.
Identify the Cisco VPN product line and the security features of these products.
Configure a site-to-site VPN GRE tunnel.
Describe the IPsec protocol and its basic functions.
Compare AH and ESP protocols.
Describe the IKE protocol and modes.
Describe IPsec negotiation and the five steps of IPsec configuration.
Explain how to prepare IPsec by ensuring that ACLs are compatible with IPsec.
Configure IKE policies using CLI.
Configure the IPsec transform sets using CLI.
Configure the crypto ACLs using CLI.
Configure a crypto map using CLI.
Troubleshoot the IPsec configuration.
Configure IPsec using CCP.
Configure a site-to-site VPN using the Quick Setup VPN Wizard in CCP.
Configure a site-to-site VPN using the step-by-step VPN Wizard in CCP.
Troubleshoot VPNs using CCP.
Explain how the corporate landscape is changing to support telecommuting.
Compare remote-access IPsec VPNs and SSL VPNs.
Explain how SSL is used to establish a secure VPN connection.
Describe the Cisco Easy VPN feature.
Configure a VPN server using CCP.
Connect a VPN client using the Cisco VPN Client software.
Chapter 8
8.0 Introduction
8.1 VPNs
8.2 GRE VPNs
8.3 IPsec VPN Components and Operation
8.4 Implementing Site-to-Site VPNs with CLI
8.5 Implementing Site-to-Site VPNs with CCP
8.6 Implementing Remote-Access VPNs
8.6 Summary
8.1 VPNs
VPN Overview
Virtual Private Networks
A Virtual Private Network (VPN) is a private network that is created via
tunneling over a public network, usually the Internet.
VPNs have multiple benefits, including:
Compatibility with broadband technology
Cost savings
Security
Scalability
VPN Overview
Types of VPNs
In the simplest sense, a VPN connects two endpoints, such as two
remote offices, over a public network to form a logical connection.
The logical connections can be made at either Layer 2 or Layer 3 of the
OSI model.
Common examples of Layer 3 VPNs are:
Generic Routing Encapsulation (GRE)
Multiprotocol Label Switching (MPLS)
Internet Protocol Security (IPsec)
VPN Topologies
Site-to-Site VPNs
Created when connection devices on both sides of the VPN
connection are aware of the VPN configuration in advance.
The VPN remains static and internal hosts have no knowledge
that a VPN exists.
8.2 GRE VPNs
Configuring a Site-to-Site GRE Tunnel
GRE Tunnels Cont.
GRE can encapsulate almost any other type of packet.
Uses IP to create a virtual point-to-point link between Cisco routers
Supports multiprotocol (IP, CLNS, ) and IP multicast tunneling (and,
therefore, routing protocols)
Best suited for site-to-site multiprotocol VPNs
RFC 1702 and RFC 2784
GRE Header
GRE encapsulates the entire original IP packet with a standard IP
header and GRE header.
GRE tunnel header contains at least two 2-byte mandatory fields:
GRE flag
Protocol type
GRE Header Cont.
GRE does not provide encryption, but it can be monitored with a
protocol analyzer.
While GRE and IPsec can be used together, IPsec does not
support multicast/broadcast and, therefore, does not forward
routing protocol packets. However, IPsec can encapsulate a GRE
packet that encapsulates routing traffic (GRE over IPsec).
Configuring GRE
1. Create a tunnel interface: interface tunnel 0
2. Assign the tunnel an IP address.
3. Identify the source tunnel interface: tunnel source
4. Identify the tunnel destination: tunnel destination
5. (Optional) Identify the protocol to encapsulate in the GRE
tunnel: tunnel mode gre ip
By default, GRE is tunneled in an IP packet.
Configuring GRE Cont.
8.3 IPSec VPN
Components and
Operation
Introducing IPsec
IPsec As an IETF Standard Cont.
Introducing IPsec
IPsec As an IETF Standard Cont.
The IPsec
framework consists
of five building
blocks.
The administrator
selects the
algorithms used to
implement the
security services
within that
framework.
Introducing IPsec
IPsec as an IETF Standard
Using the IPsec framework,

IPsec provides these essential
security functions.
Introducing IPsec
Confidentiality
Confidentiality is achieved through encryption.
Introducing IPsec
Confidentiality Cont.
Encryption algorithms
and key lengths that
VPNs use:
DES
3DES
AES
Software-
Optimized
Encryption
Algorithm (SEAL)
Introducing IPsec
Integrity
A method of proving data integrity is required to
guarantee that the content has not been altered.
A data integrity algorithm can provide this guarantee.
Hashed Message Authentication Code (HMAC) is a data
integrity algorithm that guarantees the integrity of the
message using a hash value.
Introducing IPsec
Integrity Cont.
Two common HMAC
algorithms:
HMAC-Message
Digest 5 (HMAC-
MD5)
HMAC-Secure Hash
Algorithm 1 (HMAC-
SHA-1)
Introducing IPsec
Authentication
The device on the other end of
the VPN tunnel must be
authenticated before the
communication path is
considered secure.
There are two primary methods
of configuring peer
authentication:
Pre-shared Keys (PSKs)
RSA signatures
Introducing IPsec
Authentication Cont.
Introducing IPsec
Authentication Cont.
Introducing IPsec
Secure Key Exchange
Encryption algorithms, such as
DES, 3DES, AES, and the MD5
and SHA-1 hashing algorithms
require a symmetric, shared
secret key to perform encryption
and decryption.
How do the encrypting and
decrypting devices get the
shared secret key?
The Diffie-Hellman (DH) key
agreement is a public key exchange
method that provides a way for two
peers to establish a shared secret
key that only they know.
IPsec Security Protocols
IPsec Framework Protocols
IPsec uses two main protocols to create a security framework:
AH: Authentication Header
ESP: Encapsulating Security Payload
Authentication Header
AH provides authentication and optional replay-detection
services.
It authenticates the sender of the data.
AH operates on protocol number 51.
AH supports the HMAC-MD5 and HMAC-SHA-1 algorithms.
Authentication Header Cont.
The AH process occurs in this order:
1. The IP header and data payload are hashed using the shared secret key.
2. The hash builds a new AH header, which is inserted into the original packet.
3. The new packet is transmitted to the IPsec peer router.
4. The peer router hashes the IP header and data payload using the shared secret
key, extracts the transmitted hash from the AH header, and compares the two
hashes.
ESP
ESP provides the same security services as AH (authentication
and integrity) and encryption service.
It encapsulates the data to be protected.
It operates on protocol number 50.
ESP Cont.
Please dont use bullet formatting for single sentences. Promote the sub-
bullets to level 1. ESP can also provide integrity and authentication.
First, the payload is encrypted using DES (default), 3DES, AES, or SEAL.
Next, the encrypted payload is hashed to provide authentication and data
integrity using HMAC-MD5 or HMAC-SHA-1.
Transport and Tunnel Modes
ESP and AH can be applied to IP packets in two different modes.
Transport and Tunnel Modes Cont.
Security is provided only for the Transport Layer and above. It
protects the payload but leaves the original IP address in
plaintext.
ESP transport mode is used between hosts.
Transport mode works well with GRE, because GRE hides the
addresses of the end devices by adding its own IP.
Transport and Tunnel Modes Cont.
Tunnel mode provides security for the complete original IP
packet. The original IP packet is encrypted and then it is
encapsulated in another IP packet (IP-in-IP encryption).
ESP tunnel mode is used in remote access and site-to-site
implementations.
Internet Key Exchange
Security Associations
The IPsec VPN solution
Negotiates key exchange parameters (IKE).
Establishes a shared key (DH).
Authenticates the peer.
Negotiates the encryption parameters.
The negotiated parameters between two devices are known as a
security association (SA).
Security Associations
An SA is a basic building block of IPsec. Security associations are
maintained within a SA database (SADB), which is established by
each device.
A VPN has SA entries defining the IPsec encryption parameters
as well as SA entries defining the key exchange parameters.
SAs represent a policy contract between two peers or hosts, and
describe how the peers use IPsec security services to protect
network traffic.
SAs contain all the security parameters needed to securely
transport packets between the peers or hosts, and practically
define the security policy used in IPsec.
Security Associations Cont.
Security Associations Cont.
IKE helps IPsec securely exchange cryptographic keys between
distant devices. Combination of the ISAKMP and the Oakley Key
Exchange Protocol.
Key Management can be preconfigured with IKE (ISAKMP) or
with a manual key configuration. IKE and ISAKMP are often used
interchangeably.
The IKE tunnel protects the SA negotiations.
IKE Phase 1 and Phase 2
There are two phases in every IKE negotiation
Phase 1 (Authentication)
Phase 2 (Key Exchange)
IKE negotiation can also occur in:
Main mode
Aggressive mode
The difference between the two is that Main mode requires the
exchange of six messages while Aggressive mode requires only
three exchanges.
IKE Phase 1 and Phase 2 Cont.
IKE Phase One:
Negotiates an IKE protection suite.
Exchanges keying material to protect the IKE session (DH).
Authenticates each other.
Establishes the IKE SA.
Main mode requires the exchange of six messages while
Aggressive mode only uses three messages.
IKE Phase Two:
Negotiates IPsec security parameters, known as IPsec transform
sets.
Establishes IPsec SAs.
Periodically renegotiates IPsec SAs to ensure security.
Optionally performs an additional DH exchange.
IKE Phase 1 and Phase 2 Cont.
Three Key Exchanges
Three exchanges transpire during IKE Phase 1.
The first exchange between the initiator and the responder.
Establishes the basic security policy.
Peers negotiate and agree on the algorithms and hashes that are
used to secure the IKE communications.
Rather than negotiate each protocol individually, the protocols are
grouped into sets, called IKE policy sets.
The IKE policy sets are exchanged first.
Negotiate IKE Policy
Three Key Exchanges Cont.
The second exchange creates and exchanges the DH public keys
between the two endpoints.
Negotiate IKE Policy
Using the DH algorithm, each peer generates a shared secret without
actually exchanging secrets.
In the third exchange, each end device must authenticate the other
end device before the communication path is considered secure.
The initiator and recipient authenticate each other using one of the
three data-origin authentication methods:
PSK
RSA signature
RSA encrypted nonce
IPsec Authentication
Aggressive Mode
Aggressive Mode Phase 1
Aggressive mode is another
option for IKE Phase 1.
Aggressive mode is faster
than Main mode due to
fewer exchanges.
Aggressive Mode Phase 2
IKE Phase 2
The purpose of IKE Phase 2 is to negotiate the IPsec security
parameters that will be used to secure the IPsec tunnel.
IKE Phase 2 is called quick mode.
IKE Phase 2 can only occur after IKE has established the secure
tunnel in Phase 1.
Quick mode negotiates the IKE Phase 2 SAs.
In this phase, the SAs that IPsec uses are unidirectional. A separate
key exchange is required for each data flow.
Quick Mode
8.4 Implementing Site-to-
Site IPsec VPNs with
CLI
Configuring a Site-to-Site IPsec VPN
IPsec VPN Negotiation
A VPN is a communications channel used to form a logical
connection between two endpoints over a public network.
IPsec VPN negotiation involves several steps.
IPsec VPN Negotiation Cont.
IPsec Configuration Tasks
Some basic tasks must be completed to configure a site-to-
site IPsec VPN.
Task 1. Ensure that ACLs configured on interfaces are compatible
with the IPsec configuration.
Task 2. Create an ISAKMP (IKE) policy.
Task 3. Configure the IPsec transform set.
Task 4. Create a crypto ACL.
Task 5. Create and apply a crypto map.
Task 1 Configure Compatible ACLs
Protocols 50 and 51 and UDP Port 500
Ensure that the ACLs are configured so that ISAKMP, ESP,
and AH traffic are not blocked at the interfaces used by
IPsec.
ESP is assigned IP protocol number 50.
AH is assigned IP protocol number 51.
ISAKMP uses UDP port 500.
Task 1 Configure Compatible ACLs
Configuring Compatible ACLs Cont.
Task 2 Configure IKE
The second major task in configuring Cisco IOS ISAKMP support is to
define the parameters within the IKE policy.
Multiple ISAKMP policies can be configured on each peer participating in
IPsec.
The crypto isakmp policy command invokes ISAKMP policy
configuration command mode, where you can set the ISAKMP
parameters.
Negotiating ISAKMP Policies
Two endpoints must negotiate ISAKMP policies before they agree on the
SA to use for IPsec.
Negotiating ISAKMP Policies Cont.
Policy numbers are

only locally
significant and do
not have to match
between IPsec
peers.
Pre-Shared Keys
The key string cisco123 matches.
The address identity method is specified.
The ISAKMP policies are compatible.
Default values do not have to be configured.
Task 3 Configure the Transform Sets
Configuring the Transform Sets
Transform sets are negotiated during IKE Phase 2 quick mode.
R1 has transform sets ALPHA, BETA, and CHARLIE configured, while
R2 has RED, BLUE, and YELLOW configured.
Each R1 transform set is compared against each R2 transform set in
succession until a match is found.
R1 R2
Configuring the Transform Sets Cont.
R1 R2
R1 R2
R1 R2
Task 4 Configure the Crypto ACLs
Defining Crypto ACLs
Crypto ACLs identify the traffic flows to protect.
Outbound crypto ACLs select outbound traffic that IPsec should protect.
Traffic not selected is sent in plaintext.
If desired, inbound ACLs can be created to filter and discard traffic that
should have been protected by IPsec.
Crypto ACL Syntax
Outbound crypto ACLs define the interesting traffic to be encrypted. All
other traffic passes as plaintext.
Symmetric Crypto ACL Syntax
Symmetric crypto ACLs must be configured for use by IPsec.
RouterA#(config)
access-list 110 permit tcp 10.0.1.0 0.0.0.255 10.0.2.0 0.0.0.255
RouterB#(config)
access-list 110 permit tcp 10.0.2.0 0.0.0.255 10.0.1.0 0.0.0.255
Task 5 Apply the Crypto Map
Defining Crypto Maps
Crypto maps define:
Which traffic to protect using a crypto ACL
Granularity of the flow to be protected by a set of SAs
Who the remote IPsec peers are
Local address used for the IPsec traffic (optional)
Which type of IPsec security is applied to this traffic (transform sets)
Key management method
SA lifetimes
Crypto Map Syntax
Crypto Map Syntax Cont.
Applying the Crypto Map
Verify and Troubleshoot the IPsec Configuration
Defining Crypto Maps
IPsec Show Commands
R1# show crypto map

Crypto Map MYMAP" 10 ipsec-isakmp
Peer = 172.30.2.2
Extended IP access list 102
access-list 102 permit ip host 172.30.1.2 host 172.30.2.2
Current peer: 172.30.2.2
Security association lifetime: 4608000 kilobytes/3600 seconds
PFS (Y/N): N
Transform sets={ MINE, }
The show crypto map command verifies configurations and shows the
SA lifetime.
IPsec Show Commands Cont.
R1# show crypto isakmp policy

Protection suite of priority 110
encryption algorithm: DES - Data Encryption Standard (56 bit keys).
hash algorithm: Message Digest 5
authentication method: pre-share
Diffie-Hellman group: #1 (768 bit)
lifetime: 86400 seconds, no volume limit
Default protection suite
encryption algorithm: DES - Data Encryption Standard (56 bit keys).
hash algorithm: Secure Hash Standard
authentication method: Rivest-Shamir-Adleman Signature
Diffie-Hellman group: #1 (768 bit)
lifetime: 86400 seconds, no volume limit
The show crypto isakmp policy command displays configured IKE policies
and the default IKE policy settings.
IPsec Show Commands Cont.
The show crypto ipsec transform-set command shows all

configured transform sets.
Verifying Security Associations
R1# show crypto isakmp sa
dst src state conn-id slot

172.30.2.2 172.30.1.2 QM_IDLE 47 5
show crypto ipsec sa indicates that an SA is established, the rest of

the configuration is assumed to be working.
Troubleshooting VPN Connectivity
This is an example of the Main Mode error message.
The failure of Main Mode suggests that the Phase I policy does
not match on both sides.
R1# debug crypto isakmp
1d00h: ISAKMP (0:1): atts are not acceptable. Next payload is 0 1d00h:
ISAKMP (0:1); no offers accepted!
1d00h: ISAKMP (0:1): SA not acceptable!
1d00h: %CRYPTO-6-IKMP_MODE_FAILURE: Processing of Main Mode failed with
peer at 150.150.150.1
Verify that the Phase I policy is on both peers and ensure that all
the attributes match.
Encryption: DES or 3DES
Hash: MD5 or SHA
Diffie-Hellman: Group 1 or 2
Authentication: rsa-sig, rsa-encr or pre-share

CCNAS InstructorPPT Ch8 Short

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

CCNAS InstructorPPT Ch8 Short

Încărcat de

Drepturi de autor:

Formate disponibile

Chapter 8:

By default, GRE is tunneled in an IP packet.

Using the IPsec framework,

Negotiate IKE Policy

Negotiate IKE Policy

Aggressive Mode Phase 2

Policy numbers are

R1# show crypto map

R1# show crypto isakmp policy

The show crypto ipsec transform-set command shows all

R1# show crypto isakmp sa

dst src state conn-id slot

show crypto ipsec sa indicates that an SA is established, the rest of

S-ar putea să vă placă și