grumpy networkers journal documentation...ing the ike and ipsec sessions within udp (ip protocl 17)...

Grumpy Networkers JournalDocumentation

Release 0.0.7

Head In The Cloud

Oct 17, 2019

Contents:

1 Networking 31.1 Virtual Private Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.2 Network Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

2 Security 592.1 Common Network Attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 592.2 Securing the Switch Infrastructure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 602.3 Segregating Networks using Firewalls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 602.4 Cryptography Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 652.5 Authentication Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

3 Cloud Services 693.1 Cloud Deployment Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 693.2 Cloud Service Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

4 Documentation 714.1 Sphinx . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

5 Study Notes 735.1 Cisco CCNP - Implementing Cisco Secure Mobility Solutions (300-209 SIMOS) . . . . . . . . . . . 735.2 Cisco CCNP - Implementing Cisco Edge Network Security Solutions (300-206 SENSS) . . . . . . . 745.3 Cisco CCNP - Implementing Cisco IP Switched Networks (300-215 SWITCH) . . . . . . . . . . . . 76

6 Vendor Implementations 1616.1 Cisco Implementations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161

7 To Do 207

8 Glossary of Terms 211

9 External References 2139.1 PPTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2139.2 Sphinx . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213

10 Indices and tables 215

Bibliography 217

i

Index 219

ii

Grumpy Networkers Journal Documentation, Release 0.0.7

Warning: You agree to use anything included in this journal at your own risk, I make no guarantees that anythingincluded will work in your environment or that it is even accurate.

By making this journal public I hope that it is of use to fellow network/security engineers either in teaching themnew things or troubleshooting that tricky problem.

It is highly recommended that before trying any of the listed configurations that you do you own additional researchto make sure it is compatible with your equipment and/or infrastructure.

Contents: 1


2 Contents:

CHAPTER 1

Networking

dsfsdfsdfsdfsdfd

1.1 Virtual Private Networks

1.1.1 IPSEC VPNs

IKE Version 2

Overview

IKE Version 2 or simple IKEv2 for short was published in RFC4306 but has since been updated by a number ofother RFCs, the latest being RFC 7296. It offers a number of improvements over the previous incarnation whereweaknesses have been identified. Ihis is mostly a benefit it must be understand that the two versions whilst still similarare incompatible with each other and therefore both peers must support the new version of the protocol.

The establishment of an IKEv2 VPN starts with an IKE_SA_INIT meesage whereby both peers negotiate a set ofalgorithms and agree on the secret key that is derived from additional key material. Additiona random data is added inthe form of a nonce. Once established all furter messages will be encrypted and the integrity validated.

The second part of the exchange called an IKE_AUTH is secured using the agreed properties from the first exchange.Each side of the exchange will authenticate each other using an integrity check generated from the secrets associatedwith their identity.

Peers will then exchange algorithms that will be used to protect one or more IPSEC SAs using either ESP or AH thatis then used to secure the actual user traffic.

Each time an additional IPSec is required (Such as adding a new subnet to be encypted), an additional IKEv2 exchangewill occur called a CREATE_CHILD_SA. In the case of IKEv22 these exchange are not referred to as Phase 2 SAsbut instead called a Child SA.

3


Nonce

In order to make the output of the cryptographic function less predicatable. A certain amount of randomness is added.This is the purpose of the nonce and is a randomly generated value that is used as input to the data when authenticatingpeers.

The nonce is sent by the initiator.

The nonce must be a minimum of 128 bits an up to 2048 bits in size. In practice the nonce must be at least half thesize of the output for the PRF function that is negotiated.

Denial of Service Protection

In order to offer more protection against Denial of Service IKEv2 provides defences in the form of cookies. Thesecookies are designed to defend against blind spoofing attacks as the initating party must be able to reply to the cookierequest which is a lot less computationally expensive that a real IKEv2 exchange.

In the event an IP address is spoofed, no reply will be forthcoming that the receiving party will not have wasted alot resource establishing and storing the intial state for a peer that doesnt exist. The point at which this protection isenabled is configurable when a certain number of half connections are seen.

This Denial of service protection only helps against attacks that are using faked IP addressing, in the situation wherethe real host (such as one involved in a botnet) is making the request and is able to reply resources would still beconsumed. In the case of certain vendors, this protection is not enabled by default (such as Cisco).

When enabled the initial IKE_SA_INIT is increased from a two way exchange to a four way exchange as the cookieneeds to be send and received before the IKE responder will sent cryptographic material.

Certificate Request

In IKEv1 when certificate authentication was used the subject name of the CA was included. This introducted the riskthat it could be duplicated.

In IKEv2 this has been removed and now the responder can request that the initiator use a certifiate issued from apreferred cerificate authority by sending the SHA-1 hash of the public key of any trusted CA. The peer receiving therequest can select a CA from one of those in the request.

Out-of-Band Certificate Lookup

Instead of receiving the request directly in the IKE exchange a peer can notify of it’s ability to retrieve a certificate viaHTTP instead.

The sending peer will then provide the 160-bit SHA-1 hash of the certifiate along with the URL where it can be bedownloaded from. This is useful in situations where fragmentation may occur due to the size of the certificates orcertificate chain.

It should be noted that this method of authentication is not widely supported by all devices/vendors.

Extensible Authentication Protocol (EAP)

IKEv2 includes support for EAP as a valid method of authenticating an initiator.

The responder must use a form of certificate (either RSA or ECDA) as it’s means of authentication when a reply issent to the initiator. In this instance the initiator will repond first with it’s identity.

4 Chapter 1. Networking


Initial Contact

In the event of a VPN peer crashing or other issue that causes it to loose the current cryptographic material IKEv2includes a mechanism in which to detect if an existing SA is in place and to tear it down so a new session can beestablished.

This is based on the premise that there is no point waiting resources trying to send encrypted packets to an endpointthat has no means to decrypted them. It is better to simply tear it down and start from scratch by agreeing new keyingmaterial.

Dead Peer Detection

IKEv1 included a means of sending keepalives to ensure that its peer were active and should be able to receive data.This however was wasteful on resources especially on a busy hub.

An improvement was added to IKEv1 was an option called Dead Peer Detection. Whilst similar to keepalives, it isfar more scaleable as it only sent keepalives when no data was being seen from that remote peer. As long as data wasbeing seen or no data needed to be sent, the DPD mechanism would do nothing.

One issue does exist however, because DPD will only sent a request when traffic needs to be sent over the VPN it maynot notice the failed peer straight away. By using routing protocols over the tunnel however, this should not be an issueas they will notice the failure more quickly and where redundant links exist will reconverge as necessary.

It is recommended that DPD be enabled so that in the event of failed peers the now unnecessary security assoicationscan be torn down. On the hub however if a large number of VPN peers fail this may place a lot of additional burdenon this central device. Whilst DPD should be enabled on all spoke devices, care should be taken not to set the DPDtimeout values too aggressive so that it doesn’t support from a Denial Of Service simply due to having to process tomany DPD request/replies.

NAT-T

NAT-T offers a mechanism by which IPSec traffic can be sent through a NAT device. It was an optional features inIKEv1 but is mandatory in IKEv2.

NAT-T works by encapsulating the ESP packets within a UDP packet (usually using UDP 4500) so that the NAT devicecan individually track the connections coming through it based on the source/destination port numbers. Prior to NAT-Tit was necessary for devies to support IPSec Passthrough whereby the needed to keep track of the SPI information inthe ESP headers to know what to do and this ofter limited the ability of the feature (for example only one IPSec deviceat a time).

One problem that exists is when an IPSec connection is idle it isn’t sending or receiving any data so this would causethe NAT gateway to start the idle timer because according to RFC 3715 NAT entries should have finite lifetime. Thisis taken care of by sending NAT-T keepalives at certain intervals to avoid the NAT gateway tearing down the sessions.It should be noted that these keepalive packets whilst not carrying any protected data, are not encrypted in any way. Asingle payload of 0xFF is included in the packet.

Note that because of the way in which Authentication Header (AH) validate the packet, it is still not possible to useAH and NAT with IKEv2 just as with IKEv1.

NAT detection is included as part of the protocol and when detected the peers will automatically switch to encapsulat-ing the IKE and IPSec sessions within UDP (IP Protocl 17) over port 4500 (unless configured otherwise).

IKEv2 and IKEv1 Comparison

As previously mentioned although they perform the same function IKEv1 and IKEv2 and not compatible.

1.1. Virtual Private Networks 5


Two of the biggest advantages of IKEv2 are its inclusion of Next Generation Encryption (NGE) and anti denial-of-service capabilities.

IKEv2 also includes EAP authenticaton which was not available as part of IKEv1.

The overall packet structure of IKEv2 has also been redesigned to be more efficient, needing fewer packets and lessbandwidth that IKEv1.

The current form of IKEv1 is the combination of numerous RFCs which have resulted in a number of bolt-on featuresbeing added to IKEv1. Many of these features are now included in IKEv2 by default and therefore allowed for acleaner design.

IKEv2 no longer provides for Main Mode or Aggressive mode, instead there is a single IKE_SA_INIT as coveredabove.

In IKEv1 the lifetime of the IKE SA was negotiated in the first pair of messages. This resulted in incompatibilitiesdue to mismatched values. For IKEv2 the lifetime is now a locally configured value which is not negotiated betweenpeers. A peer is responsible for deleting or rekying the SA when it’s local lifetime expires.

Whilst ECDSA authentication was introduced to IKEv1 it was late coming and therefore has seen little adoption. Ithas however seen wide adoption in IKEv2 and a requirement for implementations to support the Suite B Profile (RFC6380)

IKEv1 has no support for high availability resulting in tricks such as DNS round robin or using a dedicated loadbalancer. IKEv2 provides for a redirection ability where a client can be told to connect to another VPN gateway.

The IKEv2 provides for a wider range of traffic selectors as well as allowing the responder to select a narrower setthan the initiator proposed, this can be done per Child SA. The official standard allows for a single IPSec SA to handleboth IPv4 and IPv6 traffic however not allow Vendor (including Cisco) provide support for this.

NAT has already been covered above, NAT-T and NAT detection were originally not included as part of the IKEv1standard but they are now as part of IKEv2.

IKEv1 did not include any method for pushing configuration to peers (such as IP addressing in the case of a remoteaccess client). IKEv2 has inbuilt support for configuation data exchange via the use of a configuration payload.

In IKEv1 when pre-shared keys were used it was not possible to based identity on anything other than the peer IPaddress. Because IKEv2 does not use the shared secret as part of its initial calcuation other identity details can beused. It is assumed that because the peer was able to perform these calculations that it must have possesion of theprivate key and therefore its identify can be more trustworthy.

Because of the above IKEv1 needed to have a unique IP per pre-shared-key. IKEv2 does away with this limitation.

IKEv2 is also considered more reliable as message exchanges are sent in pairs so a response is always expected.

In IKEv1 all sets of cryptographic ciphers are transferred in seperate transforms. In IKEv2 all algorithms are sentwithin a single transform, or two where combined and non-combinded mode ciphers are used.

IKEv2 is able to provide combined mode ciphers in which a single algorithm is able to perform both encryption andintegrity protection.

In IKEv1 it was possible for an IPSec SA to exist without a corresponding IKE SA. This is due to IKEv1 not operatingin a noncontinuous channel mode. In IKEv2 this is not possible as for an IPSec SA to exist it must have a matchingIKEv2 SA.

Introduction

It’s been mentioned already in the overview of VPN technologies that IPSec is not a single protocol instead a suite ofprotocols working together to provide the necessary security services.

RFC 2401 defines the fundamental components of IPSec to be:



• Security Protocols

• Key Management

• Algorithms

Due to the way in which IPSec works it’s not easy to understand one of these components without understanding theoffers.

Encryption is a fundamental part of various IPSec functions and the relevant terminalogy will be mentioend as nece-sary. For a more detailed understanding, consult the chapters in this journal on Cryptography

These notes were written up as part of my studies for the CCNP SIMOS exam in May 2017 as served as part of myrevision. They are not intended to be complete discussion of the entire IPSec Protocol stack.

Security Protocols

The purpose of IPSec is to provide protection for the data that is being transmitted over the network. Depending onthe nature of the traffic a number of services can be offered as covered previously:

• Access Control

• Confidentiality

• Data Integrity

• Authentication

• Protection against replay

IPsec provides two protocols that offer different levels of protection to the data, these protocols are EncapsulatingSecurity Payload (ESP) and Authentication header (AH).

Each of these protocols again can be used along with different encapsulation methods depending on the type of networkthey are being used on. The methods of encapsulation are called Transport and Tunnel mode and will be covered first.

Transport vs Tunnel Mode

Transport Mode

Transport mode works by inserting the ESP or AH header between the original IP header and the upper layer protocol(e.g. UDP or TCP). The IP header remains the same except for the IP protocol field, the IP header checksum isrecalculated.

When this mode is used any routing is based on the original destination IP address. Because of this it is most use-ful when traffic between two hosts needs to be protected but becomes more difficult when moving to a site-to-sitedeployment.

When combined with GRE, transport mode still has it’s uses as in this instance the GRE endpoint serves as the hostendpoint.

Another limitation of transport mode is that it cannot used along NAT translation between two IPSec peers. In the caseof AH, this is because NAT changes the source IP address in the IP header therefore it will no longer match the AHheader causing the receiving endpoint to drop the packet.

For ESP, it is possible that NAT may work but as the higher level protocol is encrypted a NAT device cannot read morespecific information (such as port numbers) so is more limited in the type of NAT it can do. Depending on the NATdevice in front of the VPN device it may be limited to just one device, more advanced devices may be able to read theESP information (such as the SA’s) and make enough sense out of them to determine the individual connections.



It is also potentially less efficient that tunnel mode due to the encryption engine having to displace (effectively rewrit-ing) the IP header rather than just encrypting the entire packet.

The size of the packet will also be increased due to the additional headers which could lead the packet being oversizedfor the networks supported MTU. This however is not as much as concern as it is for Tunnel mode.

Tunnel Mode

Tunnel mode works by encrypting the entire original IP packet into another IP datagram and an AH or ESP header isadded between the outer and inner headers.

In the case of AH, the entire new packet is authenticated (excluding certain mutable fields, such as TTL). This meansthat it still will not work through a NAT gateway.

For ESP, everything except the new IP Header is authenticated and the original packet along with ESP trailer isencrypted. Because the new IP header is not taken account of if the packet is modifed it can pass through NAT withoutissue (assuming the NAT gateway supports IPSec Passthrough otherwise same limitates as transport mode).

The primary benefit however is that routing decisions are now based on the outer IP header meaning it can pass overpublic networks using globally unique IP addresses, keeping the inner (private) IP addresses completely hidden untilthe packet reaches the other VPN gateway.

The downside to tunnel mode however is that because it includes an additional IP header along with ESP header, trailerthis increases the packets size quite substantially which may take it over the allowed MTU of the given network.

Encapsulated Security Payload vs Authentication Header

IPSec offer two means by which the original packet data can be encapsulated.

Sometimes all that is required is to ensure that the data has not been modified other times confidentiality is essentialto offer as much protection as possible that the data has not been examined en route to it’s destination.

Encapsulating Security Payload (ESP)

The Encapsulating Security Payload header provides all of the necessary services for a secure VPN as covered underSecurity Protocols.

This implementation is achieved by enclosing the encrypted version of the orignal payload inside of an ESP headerand trailer. The ESP header is indicated by setting the upper layer protocol in the IP header to IP Protocol 50.

One of the key fields inthe ESP header is the security parameter index (SPI), this along with the destination addressand protocol in the IP header identifies the security association to be used to process the packet. The SPI can be usedto looking the SA in the security association database (SADB).

A sequence number is included in the header by the header and is simply a unique increasing number used to providereplay protection services.

It should be noted that the ESP header itself is not encrypted otherwise the remote peer would not be able to identifywhich connection the packet is associated with. It also explains why for more advanced NAT gateway’s it may bepossible for ESP traffic to pass through them without issue.

Authentication Header (AH)

Unlike ESP, Authentication Header doesn’t provide confidentiality and replay protection is optional.



AH sets the upper layer protocol in the original IP header to IP Protocol 51.

Because AH creates the authentication data based on the entire packet, it’s possible some of this may change in transitresulting in the authentication failing. To combat this the following fields are zero’d out before the authenticationdigest is hashed:

• ToS

• Flags

• Fragment Offset

• TTL

• Header checksum

Key Management And Security Associations

• Phase 2

– Quick Mode

• IPSEC Packet Processing

– SPD

– SADB

Key management is the process of generating, distributing and storing of encryption keys. In IPSec the Internet KeyExchange (IKE) protocol is is the default method for secure key negotiation.

In order to exchange keys over an insecure transport medium, IKE uses the Diffie-Hellman Key management protocol.

Diffie-Hellman Key Exchange

The DH Key Exchange depends on the discrete logarithm problem where it assumes that it is computationally in-feasable to calculate a shared secret key given two public values.

It works by calculating two values a generator (g) and a parameter (p). The two communicating parties (Alice andBob) calculate a random private value (a and b respectively). A public value is then derived using the previos ‘p’ and‘g’ values

Alice will calculate her public value as 𝑋 = 𝑔𝑎 𝑚𝑜𝑑 𝑝

Bob will calculate his public value as 𝑌 = 𝑔𝑏 𝑚𝑜𝑑 𝑝

These public values are then exchanged between Alice and Bob.

Alice then calculates 𝑘𝑎𝑏 = (𝑔𝑏)𝑎 𝑚𝑜𝑑 𝑝

Bob calculates 𝑘𝑏𝑎 = (𝑔𝑎)𝑏 𝑚𝑜𝑑 𝑝

Because 𝑘𝑎𝑏 = 𝑘𝑏𝑎 = 𝑘 they now know the shared secret key 𝑘.

Security Association

A security association (or SA for short) is a basic building block of IPSec. The SA is an entry in th SA Database(SAdB) that contains information about the security that has been negotiated between two parties for IKE or IPSec.

There are two types of SA, both of which are established between peers using the IKE protocol:

• IKE or ISAKMP SA



• IPSec SA

The IKE SA is used for traffic that controls the VPN tunnel such as when negotiating algorithms to use to encrypt IKEtraffic and to authenticate peers. There is only one IKE SA between peers and commonly has less traffic along with alonger lifetime that IPSec SAs.

IPSec SAs are used for negotiating the encryption algorithms to apply for IP traffic (the actual user data) betweenpeers. Each IPSec SA is unidirectional so there will always be at least two IPSec SAs (one in each direction). It is alsopossible to have multiple pairs of SAs as each defines a unique set of IP hosts or IP data traffic (for example one pairper source/destination network specified).

The establishment and maintenance of both types of SAs is the major function of the IKE protocol. The definitionof how this key exchange and negotiaion is done is divided into IKE (RFC 2409), ISAKMP (RFC 2408), OAKLEY(RFC 2412) as well as the ISAKMP Domain of Intepretation (RFC 2407).

Although ISAKMP and IKE are used interchangably they are different. ISAKMP provides the means to authenticatea peer and to exchange information for key exchange. IKE defines how the key exchange is done.

IKE operates in two phases in order to establish the SAs for IKE and also IPSec:

• Phase 1 provides mutual authentication of the VPN peers and establishment of the session key. This createsthe ISAKMP SA or IKE SA using DH excahnge, cookies and an ID exchange. Once established all IKEcommunication between the initiator and responder is protected with both encryption and integrity checks. Thisthen provides a secure channel so that Phase 2 negotiations can be performed safely.

• Phase 2 provides the negotiation and establishment of IPSec SAs using either the ESP or AH protocols to protectIP data traffic.

IKE Phase 1 Operation

Phase 1 can be performed in one of two modes, Main or Aggressive. Either way the result is the establishment of anISAKMP/IKE SA.

The IKE SA has a number of mandatory parameters:

• Encryption Algorithm (e.g. 3DES)

• Hash/Integrity Algorithm (e.g. SHA1)

• Authentication Method (e.g. Pre-shared keys)

• Diffie-Hellman Group (e.g. Group 2)

Other parameters are optional, such as SA Lifetime and most devices will have a default value for this if not defined(in terms of seconds or kilobytes)

Comparision of Main and Aggressive Mode

Main Mode

Main mode communicates 6 messages between peers starting with the Initiator.

It offers identity protection and flexibility in terms of the parameters and configurations that can be negotiated.

The exchange occurs as follows:

1. initiator sends initiator cookie and SA payload which contains the Phase 1 parameters.

2. The responder replies with the selected parameters for each of the proposals along with the SA header responseand the ISAKMP Header with a responder cookie



3. The 3rd and 4th messages occur when the keying materials are being exchanged. and a number of different keysare derived used for the late exchanges.

4. The 5th and 6th messages are encrypted using the keys created in the previous steps and authenticated using thehashes derived.

The proposals must be selected or denied in their entirety, the responder is not allowed to pick and choose elementsfrom different properties.

In addition in Main Mode the ID Payload is encrypted so the responder cannot determine who it is talking to thereforewhen authenticating using a pre-shared key, the identity can only be determined based on the source IP address.

Aggressive Mode

Aggressive Mode completes it’s exchange using only 3 messages which speeds up the IKE transaction processing.This speed however comes at a cost of some security.

The 3 messages are exchanged as follows: #. Initiator sends the ISAKMP header, security association, DH publicvalue,

nonce and identification ID.

1. The responder then replies with the choosen transform set for each of the proposals and the DH half key. Thismessage is authenticated but not encrypted.

2. The initiator then replied to the responder with the message authenticated so that the responder can make surethe hashes matches the one calculated.

In the past one of the primary uses for Aggressive mode was for remote access IKE clients as the responder wouldhave no prior knowledge of the source IP address of the initiator and pre-shared keys were used for authentication.

Because identities are passed in the clear and DH parameters cannot be negotiated, Agressive Mode is deemed lesssecure. As a hash of shared secret is passed in clear text, if an eavesdropper was able to intercept this an offline bruteforce attack could be used to obtain the clear-text secret.

In modern networks where sites are using dynamic IP addresses it is recommended to use digitial certificates forauthentication and not pre-shared keys. This allows Main mode to be used with the identity being established from thedetails in the certificate.

Authentication Methods

One of the parameters exchanged as part of IKE Phase 1 is the authentication method. The most common methodsused are pre-shared key and digital signatures.

Pre-Shared Key Authentication

In this method both peers must know a shared secret in advance which is communicated via an out-of-bands medium(such as courier or telephone call between the security engineers). Due to the simplicity by which the keys can beexchanged it is very widely used.

They keys used by the Diffie-Hellman exchange are derived from this pre-shared key.

As mentioned above, when pre-shared keys are used and the VPN peers do not have fixed IP addresses (such as in aremote access scenerio), Aggresive Mode is the only choice for this peers.



Digitial Signature Authentication

Peers are able to be authenticated with public key signaturues (either DSA or RSA). The Public Keys are normallyobtained as Certificates and IKI allows for the exchange of them between intitiator and responder.

The IKE Phase 1 process will exchange the public key (certificate) during the final 5th and 6th messages of a MainMode exchange. The signers public key is used to decrypt and verify the messages being sent.

Various details in the certificate can be used to identify the peer so it can be used in situations involving dynamic IPaddresses. However due to the complexity of needing to setup a Public Key Infrastructure (PKI) this is none used asoftern as it should be.

For more information on setting up a PKI and Certificate Authority Infrastructure, refer to the PKI section of thisjournal

IKE Phase 2 Operation

Once the IKE Phase 1 SAs have been establihed, Phase 2 can begin. Phase 2 only provides a single method ofoperation, known as Quick Mode. Once completed the two peers are ready to pass traffic using either ESP or AH.

As mentioned previous, a minimum of two IPSec SAs are required for two-way communication between IPSec peers.

Quick mode uses 3 message exchanges. All of these exchanges are protected by IKE and therefore encrypted andauthenticated using the same keys derived in Phase 1.

The Quick Mode Process is as follows:

1. The initiator will send the ISAKMP header and IPSec SA payload (including proposals and transforms) thatwill be used for bulk data. A new nonce is also exchanged between the peers. Because multiple quick modeexchanges may be ongoing, a Message ID is included to distinquish each transaction.

2. The responder replied with the choosen proposal along with the ISAKMP header, nonce and hash

3. In the 3rd message the initiator authenticates with a further hash value. This is then validated to avoid thepossibility of earlier packets being replayed.

Perfect Forward Secrecy

By default the IPSec Keys are derived from the same initial key which could lead to an attacker with knowledge of theinitial key being able to calculate all the current and future keys until IKE renegotiates. When Perfect Forward Secrecy(PFS) is enabled, new DH public values will be exchanged and the resulting shared secret will be used to generate newkey material.

IPSec Packet Processing

The exact way in which IPSec packets are processed by a host or router is often down to a vendor chose to implementit so the above process should be seen as a top-level overview of the communication not exactly how vendors havedesigned their various solutions.

RFC 2401 does describe a general approach that vendors should adopt to support interoperability that achieve thefunctional goals of IPSec.

This model describes two databases that IPSec implementions with maintain:

• Security Policy Database (SPD)

• Security Association Database (SADB)



Security Policy Database

The SPD defines various selectors to identify packets that require IPSec Services:

• Destination IP address

• Source IP Address

• Name

• Data sensitivity level

• Transport layer protocols

• Source and Destination Ports

One or more of these selectors will define the IP traffic encompassing the policy entry. Each entry will indicate whethertraffic matching should be bypassed, discarded or subject to IPSec processing. If to be processed by IPSec the entrieswill include an SA (or SA bundle).

Security Association Database

Each entry in the SADB defines the parameters associated with one SA. Each an IPSec SA is created, the SADB isupdated with all the parameters associated with it.

The SA entry for an inbound packet is obtained by indexing the SADB with the destination IP in the outer IP header,SPI and IPSec security protocol (either ESP or AH).

The SA entry for an outbound packet is obtained by a pointer to the SADB in the SPD.

The SADB contains the following parameters:

• Sequence Number

• Sequence Number Overflow

• Anti-replay window

• SA lifetime

• Modes

• AH authentication algorithm

• ESP authentcation algorithm

• ESP encryption algorithm

• Path MTU

IPSec Enhancements

• IKE Keepalives / DPD

• Idle Timeout

• Reverse Route Injection

• NAT-T

• Split Tunneling



IPSec and Fragmentation

1.1.2 SSL VPNs

SSL VPN Fundamentals

SSL VPN Introduction

Technology Overview

• Developed initially by Netscape

• SSL v1 (not released, v2, v3

• SSL v3.0 served as basis of TLS 1.0 - IETF standard

• Cisco SSL VPN uses TLS

SSL VPN Mode

Clientless

• No need for client installation of the PC as long as they have a supported Web Browser

• Runs through the Browser

• Gateway can proxy requests from the browser to internal resources (HTTP_, HTTPS_, FTP_)

Thin Client

• Designed for those non-web based applications that have static tcp port

• Uses Thin Client for supported protocols (such as Telnet, SSH_, RDP_, VNC_)

• Uses Java applets/ActiveX Plugins so clients must have Java installed on their PC

• Popup blockers can also cause problem

• Arbitary ports can be supported through the use of smart forwarding

Thick Client

• Requires installation of software on PC

• Not suitable for non-managed devices

• Requires Java/ActiveX installed for installation

• Provides all functionality as if user was on the LAN (assuming permitted over the VPN)

• Policies can be managed centrally



SSL VPN Connection Process

# Client initiated connection to server and requests a secure connection # Client provides a list of supported encryp-tion/integrity algorithms (Cipher suite) # TLS server replies with a cipher/hash function it also supports # Server alsosends back it’s identity in the form of a digital certificate that should be provided from a trusted CA of the client.The servers public encryption key is also sent. # Client confirms validity of certificate and generates a session key #Client encrypts session key with the services public key and sends it to server # Server decrypts session key and beginsencrypted session

Terms Used

SSL/TLS

Can operate in the following modes:

• Clientless

• Thin Client

• Thick/Fat Client (TLS/DTLS)

DTLS

Old Pages

1.1.3 Vendor VPN Implementations

Cisco VPN Implementations

Cisco IKEv1

Cisco IOS IKEv1 VPN Configuration Examples

The following configurations will be demonstrated:

Cisco IOS IKEv1 VPN Legacy Crypto Map with Pre-shared Keys

In this section we will configure a pair of Cisco IOS routers to communicate over IPSec using IKEv1 using the oldercrypto map style of config and pre-shared key authentication

It is assumed that the router already has basic IP connectivity to the public WAN and all private interfaces are config-ured. The default route is also assumed to be via the public WAN.

1. Define the pre-shared key for the remote peer

2. Define the Phase 1 ISAKMP policy

3. Define the Phase 2 IPSec Proposal and set the VPN encapsulation method

4. Define the Encryption Domain for the traffic which should be sent over the VPN

5. Combine all the various settings into a crypto map

6. Apply the crypto map to the public WAN interface



Configuration Steps

Step 1: Define the pre-shared keys

crypto isakmp key address

Step 2: Define the Phase 1 ISAKMP policy

crypto isakmp policy encryption hash group lifetime authentication pre-share

Step 3: Define the Phase 2 IPSec Proposal

crypto ipsec transform-set mode tunnel

Step 4: Define the Encryption Domain

To define the traffic to be encrypted an ACL needs to be created.

Each entry in this access list will create a new Phase 2 Security Association which will take up resources on the VPNgateways. Where it is possible to do so summarisation of networks should be done and also avoid the use of per-hostACE’s or those specifying individual ports and protocols (interface ACLS should be used for that purpose)

access-list permit

Step 5: Define the crypto map

crypto map ipsec-isakmpmatch address set transform-set set security-association lifetime seconds set peer

Step 6: Bind the Crypto Map to the receiving interface

interface crypto map



Complete example

The example below is based of the below topology:

Todo: Insert topology image

On the VPN Hub configure the following:

crypto isakmp key mysecretkey address 192.168.2.2

crypto isakmp policy 10encryption aeshash shalifetime 86400group 14authentication pre-share

crypto ipsec transform-set ESP-AES128-SHA1 esp-aes 128 esp-sha-hmacmode tunnel

ip access-list extended EACL-R1-TO-R2permit ip 10.1.0.0 0.0.255.255 10.2.0.0 0.0.255.255

crypto map CM-PUBLIC-WAN 10 ipsec-isakmpmatch address EACL-R1-TO-R2set peer 192.168.2.2set transform-set ESP-AES128-SHA1set security-association lifetime seconds 28800

interface FastEthernet0/0crypto map CM-PUBLIC-WAN

On the VPN Spoke configure the following:

crypto isakmp key mysecretkey address 192.168.1.1

crypto isakmp policy 10encryption aeshash shalifetime 86400group 14authentication pre-share

crypto ipsec transform-set ESP-AES128-SHA1 esp-aes 128 esp-sha-hmacmode tunnel

ip access-list extended EACL-R2-TO-R1permit ip 10.2.0.0 0.0.255.255 10.1.0.0 0.0.255.255

crypto map CM-PUBLIC-WAN 10 ipsec-isakmpmatch address EACL-R2-TO-R1set peer 192.168.1.1set transform-set ESP-AES128-SHA1set security-association lifetime seconds 28800

interface FastEthernet0/0

(continues on next page)



(continued from previous page)

crypto map CM-PUBLIC-WAN

Verification

Once the VPN configuration has been applied, it will likely be necesary to generate some traffic which matches theencryption domain in order for the vpn establishment to start.

In this example we have a loopback interface configured on both the hub ( 10.1.1.1) and spoke (10.2.1.2) so initiatinga ping between these hosts should be sufficient.

Because the Hub could be busy with dealing with other VPNs, lets does this on the spoke instead as follows:

ping 10.1.1.1 source 10.2.1.2

The first few pings are likely to fail whilst the VPN is coming up but after that they should reply without issue.

If the pings are replying we can probably assume that the VPN is up but how do we know for sure.

Firstly lets check if the Phase 1 SA is up:

show crypto isakmp sa detail

The output should be similar to that below:

C-id Local Remote I-VRF Status Encr Hash Auth DH Lifetime Cap.1001 192.168.2.2 192.168.1.1 ACTIVE aes sha psk 14 23:59:53

If the status is showing a ACTIVE that is good as it means the VPN is believed to be stable and no further action isbeing taken. If is saying anything else it could indicate the VPN is having issues or that it is renegotiating (such asduring a rekey after the lifetime has expired).

We can also see that the Phase 1 properties have negotiated to what we configured.

Assuming all is well, lets check that packets are being successfully encrypted and decrypted as follows:

show crypto ipsec sa peer 192.168.1.1

And the output should then be as follows:

interface: FastEthernet0/0Crypto map tag: CM-PUBLIC-WAN, local addr 192.168.2.2

protected vrf: (none)local ident (addr/mask/prot/port): (10.2.0.0/255.255.0.0/0/0)remote ident (addr/mask/prot/port): (10.1.0.0/255.255.0.0/0/0)current_peer 192.168.1.1 port 500PERMIT, flags={origin_is_acl,}#pkts encaps: 9, #pkts encrypt: 9, #pkts digest: 9#pkts decaps: 9, #pkts decrypt: 9, #pkts verify: 9#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.: 192.168.2.2, remote crypto endpt.: 192.168.1.1path mtu 1500, ip mtu 1500, ip mtu idb FastEthernet0/0





current outbound spi: 0xA464B844(2758064196)PFS (Y/N): N, DH group: none

inbound esp sas:spi: 0xAA697053(2859036755)

transform: esp-aes esp-sha-hmac ,in use settings ={Tunnel, }conn id: 5, flow_id: 5, sibling_flags 80004040, crypto map: CM-PUBLIC-WANsa timing: remaining key lifetime (k/sec): (4311956/28771)IV size: 16 bytesreplay detection support: YStatus: ACTIVE(ACTIVE)

outbound esp sas:spi: 0xA464B844(2758064196)

transform: esp-aes esp-sha-hmac ,in use settings ={Tunnel, }conn id: 6, flow_id: 6, sibling_flags 80004040, crypto map: CM-PUBLIC-WANsa timing: remaining key lifetime (k/sec): (4311956/28771)IV size: 16 bytesreplay detection support: YStatus: ACTIVE(ACTIVE)

The key information here, is whether packets are being encrypted and decrypted. If they are all is well and no futheraction should be necessary.

Other details that can be found out are whether the correct encryption and hashing is in place, whether PFS is beingused, if reply detection is enabled and finally the remaining lifetime of the IPSec SA.

The SPI’s shown for both the inbound and outbound direct can be useful when performing packet captures as part oftroubleshooting as they are not encrypted so can be used to identify a given VPN connection where possible a few arecoming from the same IP address (e.g. with multiple ACE entries in the encryption domain)

Troubleshooting

Problem: ISAKMP SA state reports ‘MM_KEY_EXCH’ and remote peer reports ‘%CRYPTO-4-IKMP_BAD_MESSAGE: IKE message from failed its sanity check or is malformed’

Solution: Verify that the pre-shared key is configured correctly on both peers.

Problem: Report peer reports ‘phase 1 SA policy not acceptable!’ and local peer does not establish an ISAKMP SA.

Solution: Verify that both peers have a matchin Phase 1 Policy, encryption, hashing and DH group need to be thesame on at least one policy.

Cisco IOS IKEv1 VPN with Static VTI with Pre-shared Keys

In this section we will configure a pair of routers to communicate over a statically configured VTI using GRE overIPSec.

This is useful in situations where you need to carry non-IP traffic through IPSEC.

It is assumed that the router already have basic IP connectivity and WAN routing is in place.

After the IPSec tunnel is configured working we will also setup dynamic routing through the tunnel.



Configuration Steps

1. Configure the PSK Keyring

2. Configure the ISAKMP Policy

3. Configure the ISAKMP Profile

4. Configure the IPSec Proposal

5. Configure the IPSec Profile

6. Configure the VTI tunnel using GRE over IPSec encapsulation

7. Configure routing via the tunnel

Step 1: Define the PSK Keyring

crypto keyring pre-shared-key address key

Step 1: Confifigure the ISAKMP Policy

crypto isakmp policy authentication pre-sharedencryption hash group lifetime

Step 3: Configure the ISAKMP Profile

crypto isakmp profile match identity address keyring

Step 4: Configure the IPSec Transform Set

crypto ipsec transform-set mode transport

Step 5: Configure the IPSec Profile

crypto ipsec profile set transform-set set security-association lifetime seconds set isakmp-profile



Step 6: Configure the VTI interface

interface Tunnel tunnel mode gre iptunnel source tunnel destination tunnel protection profile ipsec ip address no shutdown

Step 6a: Configure routing (EIGRP)

router eigrp no auto-summarynetwork nework

Step 6a: Configure routing (EIGRP)

router ospf

interface tunnel ip ospf area ip ospf network point-to-point

Complete Example

The hub could be configured as follows:

crypto keyring VTI-KEYRINGpre-shared-key address 192.168.2.2 key mysecretkey

crypto isakmp policy 10authentication pre-shareencryption 3deshash md5group 2lifetime 86400

crypto isakmp profile VTI-ISAKMP-PROFmatch identity address 192.168.2.2keyring VTI-KEYRING

crypto ipsec transform-set ESP-3DES-MD5 esp-3des esp-md5-hmacmode transport

crypto ipsec profile VTI-IPSEC-PROFset transform-set ESP-3DES-MD5set security-association lifetime seconds 28800set isakmp-profile VTI-ISAKMP-PROFset pfs group2





interface Tunnel 12tunnel mode gre iptunnel source FastEthernet0/0tunnel destination 192.168.2.2tunnel protection ipsec profile VTI-IPSEC-PROFip address 10.255.12.1 255.255.255.0no shutdown

router eigrp 10no auto-summarynetwork 10.255.12.0 0.0.0.255network 10.1.0.0 0.0.255.255

The spoke could be configured as follows

crypto keyring VTI-KEYRINGpre-shared-key address 192.168.1.1 key mysecretkey


crypto isakmp profile VTI-ISAKMP-PROFmatch identity address 192.168.1.1keyring VTI-KEYRING

crypto ipsec transform-set ESP-3DES-MD5 esp-3des esp-md5-hmacmode transport

crypto ipsec profile VTI-IPSEC-PROFset transform-set ESP-3DES-MD5set security-association lifetime seconds 28800set isakmp-profile VTI-ISAKMP-PROFset pfs group2

interface Tunnel 12tunnel mode gre iptunnel source FastEthernet0/0tunnel destination 192.168.1.1tunnel protection ipsec profile VTI-IPSEC-PROFip address 10.255.12.2 255.255.255.0no shutdown




Cisco IOS IKEv1 VPN with Dynamic VTI with Pre-shared Keys

In this section we will configure a hub router that is able to offer VPN tunnels to a unknown number of dynamic VPNpeers

This is useful where you may need to rapidly deploy a varied number of sites and do not want to have to reconfigurethe hub router everytime a new site is activated.

The configuration we will be putting in place is suitable when the remote peers are using dynamic IP addressing butnote that as we are using pre-shared key authentication the same key will be accepted from any IP address. This is notas secure as it could be and in a production deployment the use of digital signatures should be considerd.

It is assumed that the router already have basic IP connectivity and WAN routing is in place.

After the IPSec tunnel is configured working we will also setup dynamic routing through the tunnel.

Configuration Steps

On all devices: #. Configure a loopback to use a tunnel IP #. Configure the Keyring #. Configure the ISAKMPPolicy #. Configure the ISAKMP Profile #. Configure the IPSec Proposal #. Configure the IPSec Profile #. Configuredynamic routing

On the Hub: #. Configure the tunnel interface template

On the Spokes: #. Configure a static tunnel interface

Step 1: Define the Loopback Interface

interface loopback ip address 255.255.255.255

Step 1: Define the PSK Keyring

For the hub it’s necessary to define a wildcard PSK if the spokes will be using dynamic IP addresses. If they will bestatic they can be defined individually but that would loose some of the flexibility of the solution.

crypto keyring ! note the use of a wildcard key, this is used by any connecting peerpre-shared-key address 0.0.0.0 key

On the spokes the PSK can be defined with just the Hubs IP: .. code-block:: none

crypto keyring pre-shared-key address key

Step 1: Configure the ISAKMP Policy

crypto isakmp policy authentication pre-sharedencryption hash group lifetime



Step 3: Configure the ISAKMP Profile

crypto isakmp profile match identity address 0.0.0.0keyring virtual-template

Step 4: Configure the IPSec Transform Set

crypto ipsec transform-set mode tunnel

Step 5: Configure the IPSec Profile

crypto ipsec profile set transform-set set security-association lifetime seconds set isakmp-profile

Step 6: Define the tunnel interfaces

On the Hub we will configure a template that will be cloned each time a client connects.

interface virtual-template type tunnelip unnumbered loopback tunnel mode ipsec iptunnel destination dynamictunnel source tunnel protection ipsec profile

On the Spokes we can configure a nubmer tunnel interface:

interface Tunnel ip unnumbered loopback tunnel mode ipsec iptunnel destination tunnel source tunnel protection ipsec profile

Complete Example

The Hub config could be performed as follows:

interface loopback 0ip address 10.0.0.1 255.255.255.255

crypto keyring DVTI-KEYRINGpre-shared-key address 0.0.0.0 key mysecretkey






crypto isakmp profile DVTI-ISAKMP-PROFmatch identity address 0.0.0.0keyring DVTI-KEYRINGvirtual-template 1

crypto ipsec transform-set ESP-3DES-MD5 esp-3des esp-md5-hmacmode tunnel

crypto ipsec profile IPSEC-PROFset transform-set ESP-3DES-MD5set security-association lifetime seconds 28800set isakmp-profile DVTI-ISAKMP-PROF

interface virtual-template 1 type tunnelip unnumbered loopback0tunnel mode ipsec ipv4tunnel destination dynamictunnel source FastEthernet0/0tunnel protection ipsec profile IPSEC-PROF


The Spokes could then be configured as follows:

interface loopback 0ip address 10.0.0.2 255.255.255.255


crypto keyring DVTI-KEYRINGpre-shared-key address 192.168.1.1 key mysecretkey

crypto isakmp profile DVTI-ISAKMP-PROFmatch identity address 192.168.1.1keyring DVTI-KEYRING

crypto ipsec transform-set ESP-3DES-MD5 esp-3des esp-md5-hmacmode tunnel

crypto ipsec profile IPSEC-PROFset transform-set ESP-3DES-MD5set security-association lifetime seconds 28800





set isakmp-profile DVTI-ISAKMP-PROF

interface tunnel 12ip unnumbered loopback 0tunnel mode ipsec ipv4tunnel source FastEthernet0/0tunnel destination 192.168.1.1tunnel protection ipsec profile IPSEC-PROF


When ever a new spoke needs to be deployed the same config as above can be used, just change the following:

1. Loopback IP

2. Subnets advertised by routing protocol

• Static VTI Based IKEv1 VPN

• Dynamic VTI Based IKEv1 VPN

• Software-Based Remote Access IKEv1 VPN (Legacy IPSec Client)

• Hardware-Based Remote Access IKEv1 VPN (EasyVPN Client)

Cisco ASA IKEv1 VPN Configuration Examples

The following configurations will be demonstrated:

Cisco ASA IKEv1 VPN Configuration with Pre-Shared Keys Example

Introduction

In this example we’ll configure a Cisco ASA to talk with a remote peer using IKEv1 with symmetric pre-shared keys.

Configuration Steps

1. Define the Encryption Domain

2. Specify the Phase 1 Policy

3. Specify the Phase 2 Proposal

4. Define the connection profile

5. Configure the Crypto Map

6. Bind the Crypto Map to the appropriate interface

7. Enable IKEv1 on the appropriate interface



Define the Encryption Domain

The encryption domain specifies traffic that should be encapsulated within IPSec prior to leaving the external interface.Any traffic not matching this ACL will be sent out the interface in plain text, assuming it does not match any otherconfigured VPNs.

The ACL should also take into account of any NAT’ing that has taken place as the encryption occurs post-NAT.

access-list permit →˓

Specify the Phase 1 Policy

crypto ikv1 policy encryption hash group lifetime authentication pre-share

Specify the Phase 2 Proposal

In newer releases on Tunnel mode is support, Transport has been removed

crypto ipsec ikev1 transform-set →˓

Define the connection profile

In general speak a connection profile defines the properties of how the VPN will run and what access will be permitted.It is called as such in the ASDM but through the CLI we need to configure a tunnel-group

In earlier versions of the ASA code (pre-8.0) the preshared key was configured globally as with earlier IOS versions.

tunnel-group ipsec-l2ltunnel-group ipsec-attributes

ikev1 pre-shared-key tunnel-group general-attributes! Define additional settings such as default group policy

Configure the Crypto Map

Only a single Crypto Map can be bound to an interface, so if one already exists use a different sequence number toexisting entries.

If remote access is configured it is important to ensure that site-to-site entries have a lower sequence nubmer than theremote access one.



crypto map match address crypto map set peer crypto map set transform-set crypto map set security-association lifetime seconds

Bind the Crypto Map to the interface

If this is the first VPN (either IKEv1 or IKEv2) being setup, it will be necessary to bind the Crypto Map to the interfacefacing the remote peer(s). Otherwise this will already have been configured.

crypto map interface

Enable IKEv1 on the the interface

If this is the first IKEv1 VPN being setup, it will be necessary to bind the Crypto Map to the interface facing theremote peer(s). Otherwise this will already have been configured.

crypto ikev1 enable

Cisco IKEv2

Cisco IOS IKEv2 VPN Configuration Example

Cisco ASA IKEv2 Configuration Example

Cisco ASA IKEv2 VPN Configuration with Assymetric Pre-Shared Keys Example

Introduction

In this example we’ll configure a Cisco ASA to talk with a remote peer using IKEv2 with assymetric pre-shared keys.

Configuration Steps

1. Define the Encryption Domain

2. Specify the Phase 1 Policy

3. Specify the Phase 2 Proposal

4. Define the connection profile

5. Configure the Crypto Map

6. Bind the Crypto Map to the appropriate interface

Define the encryption domain

access-list



Define the Phase 1 Policy

The ASDM location for these settings is:

Configure → Site-To-Site VPN → Advanced → IKE Policies

crypto ikev2 policy encryption integrity group lifetime

Define the Phase 2 Proposal


Configure > Site-To-Site VPN-> Advanced > IPSec Proposals (Transform Sets)

crypto ipsec ikev2 ipsec-proposal protocol esp encryption protocol esp integrity

Define the connection profile


:menuselect:‘Configure –> Site-To-Site VPN –> Advanced –> Tunnel Groups‘

tunnel-group type ipsec-l2ltunnel-group ipsec-attributes

ikev2 local-authentciation pre-shared-key ikev2 remote-authentcation pre-shared-key

tunnel-group general-attributes! Define other properties, such as default group policy

Define the crypto map

when creating the connection profiles in ASDM, part of the configuration includes the interface and protocols to beallowed. The selection can be seen on the connection profiles section of ASDM:

Configure → Site-To-Site VPN → Advanced → Crypto Maps

crypto map match address crypto map set peer crypto map set ikev2 transform-set crypto map set security-association lifetime seconds

Bind the Crypto Map to the interface

If this is the first VPN (either IKEv1 or IKEv2) being setup, it will be necessary to bind the Crypto Map to the interfacefacing the remote peer(s). Otherwise this will already have been configured.



In ASDM as soon as any VPN is configured it will automatically bind a crypto map to the selected interface. Thebinding can be seen at the following location:

Configure > Site-To-Site VPN > Connection Profiles

crypto map interface

Enable IKEv1 on the the interface

If this is the first IKEv2 VPN being setup, it will be necessary to bind the Crypto Map to the interface facing theremote peer(s). Otherwise this will already have been configured.

In ASDM the selection of which protocol is enabled per-interface, can be seen on the connection profiles section:

Configure > Site-To-Site VPN > Connection Profiles

crypto ikev2 enable

Cisco IKEv2 Overview

This section covers details specific to the Cisco implementation of IKEv2. For a more general review, see IKE Version2.

Implementation Guides

Cisco AnyConnect Overview

Cisco Anyconnect Clientless

Cisco Anyconnect Clientless ASA Implementation

TBC

Cisco Anyconnect Clientless IOS Implementation

TBC

Configuration Steps

1. Generate RSA Keys for use with SSL/TLS

2. Enable AAA

3. Enable the HTTP/HTTPS Server

4. Configure the WebVPN Gateway

5. Configure the WebVPN Context

6. Configure Local Accounts



Generate RSA Keys

In order for the HTTP Server to also provide SSL/TLS services we need to generate the public and private keys that itwill use:

crypto key generate rsa modulus

Enable AAA

So that users can be authenticated and authorised, its necessary to enable the AAA sub-system and optionally differenta method list specifying how users should be authenticated.

! Enable the AAA sub-systemaaa new-model

! Optional - Define a specific method list for WebVPN authenticationaaa authentication login local

Enable the HTTP/HTTPS Server

In order for users to be able to access the SSL Portal, an HTTP/HTTPS server must be enabled on the IOS router asfollows:

ip http serverip http secure-server

Configure the WebVPN Gateway

To accomplish this the following information is needed:

• IP Address

• Port Number

webvpn gateway ip address port

! Optional - Configure gateway hostname, should match certificate usedhostname

! Optional - Redirect HTTP to HTTPShttp-redirect

! Optional - Specify supported cipher suitesssl encryption [aes-sha1] [3des-sha1] [rc4-md5]

! Enable the gatewayinservice



Configure the WebVPN Context

A WebVPN context is a means by which a certain portal type can be displayed to users. The context can either bespecified by the user or provided as part of the users authorization properties (e.g. from RADIUS).

webvpn context

! Optional Specify how users should be authenticated, global config will! be used if not specifiedaaa authentication list

! Create a policy for this context (multiples can exist)policy group ! All the below settings are optional

banner hide-url-barport-forward timeout [idle


http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/sec_conn_sslvpn/configuration/15-mt/sec-conn-sslvpn-15-mt-book/sec-conn-sslvpn-ssl-vpn.html

SSL VPN Remote User Guide

http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/sec_conn_sslvpn/configuration/15-mt/sec-conn-sslvpn-15-mt-book/sec-conn-sslvpn-remote.html

TBC

Cisco Anyconnect Full Client

Cisco Anyconnect Full Client ASA Implementation

TBC

Cisco Anyconnect Full Client IOS Implementation

TBC

TBC

TBC

Anyconnect Client Requirements

TBC

Cisco Dynamic Multipoint VPN (DMVPN)

Cisco Dynamic Multipoint VPN with PSK Basic Configuration

In this section 3 routers will be configured to provide a basic DMVPN. One of the routers will act as a hub, theremaining two as the spokes.

Hub Configuration Steps

Step 1: Define the IKE Phase 1 Policy

crypto isakmp policy encryption hashing authentication pre-sharegroup lifetime


http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/sec_conn_sslvpn/configuration/15-mt/sec-conn-sslvpn-15-mt-book/sec-conn-sslvpn-ssl-vpn.htmlhttp://www.cisco.com/c/en/us/td/docs/ios-xml/ios/sec_conn_sslvpn/configuration/15-mt/sec-conn-sslvpn-15-mt-book/sec-conn-sslvpn-ssl-vpn.htmlhttp://www.cisco.com/c/en/us/td/docs/ios-xml/ios/sec_conn_sslvpn/configuration/15-mt/sec-conn-sslvpn-15-mt-book/sec-conn-sslvpn-remote.htmlhttp://www.cisco.com/c/en/us/td/docs/ios-xml/ios/sec_conn_sslvpn/configuration/15-mt/sec-conn-sslvpn-15-mt-book/sec-conn-sslvpn-remote.html


Step 2: Define the Pre-Shared Key

! Same key used for all spokes regardless of IP Addresscrypto isakmp key address 0.0.0.0

Step 3: Define the IPSec Proposal

crypto ipsec transform-set mode { tunnel | transport }

Step 4: Define the IPsec Profile

crypto ipsec profile set transform-set set security-association lifetime seconds

Step 5: Create the tunnel interface

interface tunnel ip address tunnel mode gre multipoint

tunnel key tunnel source

ip nhrp nhs map multicast dynamicip nhrp authentication ip nhrp network-id ip nhrp holdtime

tunnel protection ipsec profile

no shutdown

Spoke Configuration Steps

Step 1: Define the IKE Phase 1 Policy

crypto isakmp policy encryption hashing authentication pre-sharegroup lifetime



Step 2: Define the Pre-Shared Key

! Same key used for all spokes regardless of IP Addresscrypto isakmp key address 0.0.0.0

Step 3: Define the IPSec Proposal

crypto ipsec transform-set mode { tunnel | transport }

Step 4: Define the IPsec Profile

crypto ipsec profile set transform-set set security-association lifetime seconds

Step 5: Define the Tunnel Interface

inteface tunnel ip address tunnel mode gre multipointtunnel key

ip nhrp map ip nhrp nhs ip nhrp map multicast

ip nhrp authentication ip nhrp network-id ip nhrp holdtime

Routing Protocol Considerations

DMVPN can work with either Link State or Distance Vector protocols. However considerations need to be made foreach.

Distance Vector Protocols

In order to use routing protocols such as EIGRP and RIP, it necessary to disable split horizon so that routing adver-tisements from the spokes can be readvertised out of the single hubs interface.

In addition the routing updates should still contain the original peer that advertised them, not the hops. To achieve thisNext Hop Self should be disabled.

In the case of EIGRP these can be configured on the tunnel interface as follows:



interface tunnel no split-horizon eigrp no next-hop-self eigrp

Link State Protocols

Routing protocols such as OSPF will automatically ensure all peers receiving the routing updates because this is theDesignated Routers (DR) responsibility. It however important to ensure that none of the spokes can become the DR.

It is also vital that the tunnel interface is set to us the network type of “broadcast” to ensure that the DR/BDR electionoccurs. If this is not set and more than two router Ids are seen on the same subnet, this could result in flappingneighbour relationships.

The above can be achieved by setting the priority of the spokes to 0 and manually setting the network type on thetunnel as shown below:

interface tunnel ip ospf network broadcastip ospf priority 0

When using dual-hub, its important that the priority of the primary hub is higher than that of the secondary. In the caseof a primary hub failure, the spokes will notice for themselves when the hold time has expired and automatically startqueying the secondary NHS.

Introduction

Dynmaic Multipoint VPN is a solution developed by Cisco that aimed to make large scale VPN deployments easierwithout needing to know all the endpoint in advance.

It can be used for a traditional hub-and-spoke model especially when combined with endpoints that do not have fixed IPaddresses but it’s really value comes from allowing direct spoke-to-spoke traffic, removing the burdan and potentionalbottleneck from a central hub.

As well as the existing requirements for IPSec, three additional functional components are needed:

• Multipoint GRE Interfaces

• Next Hop Resolution Protocol (NHRP)

• IPSec Proxy Instantiation

Multipoint GRE interfaces

One of the problems with having to establish a large number of individual GRE tunnels is that each one takes upresources on the central router, the most critical of which is the Interface Descriptor Block (IDB) for which there areonly a limited number.

In addition for traditional static GRE tunnels the source and destination addressing needs to be known in advancewhich is not possible where VPN endpoints could be using dynamic IP addressing.

Multipoint GRE, or mGRE solves both these issues.

An mGRE interface is a single interface from which all GRE tunnels from the spokes can be termined. This removesa lot of repetative configuration and reducing the memory resource allocation as the mGRE interface only consumes asingle IDB regardless of the number of tunnels.



When configuring the mGRE interface, only the tunnel source is specified, not the destination. An additional method isneeded to communicate this information so the hub is aware of the remote peers tunnel endpoint IP. This is performedby the Next Hop Resolution Protocol (NHRP)

Compared to individual tunnel interfaces, an multipoint interface is configured with a single subnet not a subnet pertunnel. This does cause issues with how route selection is done with certain routing protocols.

Next Hop Resolution Protocol (NHRP)

NHRP can be thought of as a Layer 3 ARP. Its role is to map the private IP used in the DMVPN “cloud” against theremote peers current public IP.

The private IP will be used within all routing updates as the advertising endpoint but it is the public IP that is neededin order to establish the dynamic tunnel between two spoke sites.

The Hub will be configured to dynamically resolve NHRP requests based on its available information. At the startit will not know of any endpoints and simply waits for a spoke to register and then for other spokes to query it forinformation.

Upon initial bootup the spokes will establish a permenant tunnel with the spoke and register their private IP againsttheir public IP using NHRP. The first time a spoke needs to communicate with a subnet located at a different spoke itwill ask the hub (via an NHRP query) for the public IP associated with the private IP shown in the routing table. Oneobtained the spoke will store this information locally for a certain period of time and also update its CEF adjacencytable to allow for faster forwarding of packets.

Once the spoke knows how to communicate with another spoke it can dynamically establish the VPN tunnel with theother spoke without any prior knowledge that the spoke existed.

Dynamic IPSec Proxy Instantiation

In traditional VPNs it necessary to do one of the following

1. Manually configure an encryption domain ACL to specify what traffic should be permitted over the VPN.

2. Establish a GRE tunnel over IPSEC with the encryption domain being predefined as all GRE traffic between thetwo GRE peers.

If no prior knowledge of the routes or peers is known, neither option is feasible.

Through NHRP a spoke is able to determine the remote spokes public IP which can then be used as the IKE remoteidentity. Because the traffic is encapsulated within GRE prior to being encrypted the subnets used over the VPN arenot relevant and the IPSec proxy profile will be the GRE traffic between the two internal IP addresses just like with atraditional GRE-over-IPSec tunnel.

There is still however the issue of how to authenticate the spokes. A number of methods can be used:

1. Pre-configure a unique key per IKE identity (spoke)

2. Pre-configure a global (wildcard) pre-shared-key for every IKE identity

3. Implement a public key infrastructure.

If any of the peers have dynamic IP addresses using a unique key is simply not possible. Even if the peers are all static,having to manage all the keys becomes increasing difficult as the number increases as all possible peers need to beupdated.

Using a global pre-shared-key would seem the simplest solution and in general is widely used, it needs to be understoodhowever that making updates to this key is difficult and leads to a “flag day” where all devices need to be updated atonce. This is generally frowned upon by businesses and operations teams.



The final solution is to use a PKI, this is certainly the most scaleable solution as it doesn’t require any prior peerrelationship configuration and as long as no changes are made to the central CA, changes can be made (e.g. reissuingof certificates) without affecting all devices. It does however require more prior work in order to implement the PKIand issue certificates out to all participating devices.

Once a spoke knows what public IP to communicate with and how to authenticate to it, the dynamic tunnel can beestablished and if successful traffic will then flow directly between the spokes and not through the hub.

Establishing a Dynamic Multipoint VPN

Below is a step-by-step review of how to setup spoke-to-spoke communication within a DMVPN.

Step 1: Setup the Hub site

Before any of the spokes can communicate it’s necesary for the hub to be established. Because all the spokes will beconfigured with a static NHRP entry for the hub, it cannot have any dynamic IP address.

On the hub, a point-to-multipoint tunnel will be created that has a static IP address within the DMVPN Cloud„ this isknown as the NBMA address and will show up in various command outputs.

In order to secure the DMVPN traffic, the usual configuration elements required for IPSec IKEv1 are required, namely:

1. IKE Phase 1 Policy

2. IPSec transform set

3. Authentication details (unique/wildcard PSK or RSA Signatures)

4. IPSec Profile

The tunnel interface will then be configured for protection using the IPSec profile.

Note that a static encryption domain is not created. These will be created dynamically as required by each of thespoke-to-spoke tunnels.

Finally it is necessary for the hub to accept dynamic NHRP registrations and queries. NHRP must be setup with aunique network ID for the DMVPN cloud as well as an optional authentication password. Various timers can also beadjusted to determine how long to hold onto adjancy information given by the spokes.

Depending on the routing protocol used it may also be necesary to specify certain additional properties. This will becovered later.

Steps 2:

Once the hub is ready to accept connections we can now configure the spokes. Practically all of this configuration willbe repeated for the spokes, the key changes being:

• IP address assigned to the tunnel interface

• The networks that are advised through the tunnel as part of the routing protocol.

As with any VPN tunnel, we first need to configure the IKE Phase 1, authentication details and IPSec Phase 2Transform set. These details should match what has been configured on the hub.

Next the mGRE tunnel interface needs to be configured. This is where the bulk of the configuration will beplaced as it is necessary to:

1. Define the source IP/interface of the tunnel

2. Define the tunnel (private) IP address of the spoke



3. Define the private and public IP address of the Hub

4. Define which IP address to query for NHRP mappings, the next hop server

5. Define the network ID for this DMVPN network

6. Configure any properties specific to the routing protocol

7. Specify which IPSec profile to use to encrypt the traffic

It is not necessary to define the actual Hub as the tunnel endpoint as this will be handled by the Next Hop Server.This tunnel interface will be used for all connections, both hub and spoke.

DMVPN Redundancy

DMVPN redundacy can be implemented using one of two methods: #. Configure redundant hubs #. Configureseperate mGRE subnets, effectively to seperate DMVPN networks

With a single DMVPN and redundant hubs the network is subject to the limitations of a single routing protocol.Where as if two DMVPN subnets are used it allows for flexibility in the assignemnt of unique routing protocols andcost metrics for the two networks.

In IOS versions prior to 12.(4.2) it was necessary to assign a unique IKE identity (IP address) per DMVPN.

In the case of a single DMVPN network with dual hubs the decision on which hub to use is left to the routing protocol.The secondary hub as well as acting as an NHS will also be a client to the primary NHS. If the primary hub were tofail eventually the records would time out and the spokes would query the secondary NHS instead. Routing betweenthe spokes will be determined by the routing protocol.

Cisco FlexVPN

Cisco FlexVPN Basic Client/Server Configuration

Overview

This configuration will demonstrate the absolute minimum configuration that is required in order to get a FlexVPNspoke acting as a client to establish a vpn tunnel to a FlexVPN hub acting as the server.

FlexVPN Server Configuration

The following elements must be configured on the Hub acting as the FlexVPN server:

1. Enable AAA

2. Define the local subnets to be encrypted

3. Create Address Pool

4. IKEv2 Keyring

5. IKEv2 Authorisation Policy

6. IKEv2 Profile

7. IPSec Profile

8. Tunnel interface template

It is assumed that basic LAN/WAN connectivity and routing is already in place and tested.



Enable AAA

In case we need to configure multiple differnet authorisation policies we won’t change the default authorisation list,instead creating one unique for this deployment.

This for example would allow one method to use local PSKs and another using RADIUS if so needed.

aaa new-modelaaa authorization network local

Define the local subnets

ip access-list standard permit

Create the Address Pool

ip local pool

Configure the IKEv2 Keyring

For this example we will be using symmetric pre-shared keys but it is also possible to use assymetric by specifyingdifferent ‘local’ and ‘remote’ values.

crypto ikev2 keyring peer address

pre-shared-key

Configure the IKEv2 Authorisation policy

The authorisation policy specifies the attributes that will apply to clients who are successfully authorised against thispolicy.

crypto ikev2 authorization policy ! Define the pool used to give clients an IP addresspool

! Specify the local subnets that will be advertised to clients (split-tunnel)route set access-list

Define the IKEv2 Profile

crypto ikev2 profile match identity remote address authentication remote pre-shareauthentication local pre-share





keyring local aaa authorization group psk list default virtual-template

Define the IKEv2 Profile

crypto ipsec profile set ikev2-profile

Define the interface template

interface virtual-template ip unnumbered tunnel source tunnel mode ipsec ipv4tunnel protection ipsec profile

FlexVPN Client Configuration

We will configure the following elements:

1. Enable AAA

2. Define the local subnets to be encrypted

3. IKEv2 Keyring

4. IKEv2 Authorisation Policy

5. IKEv2 Profile

6. IPSec Profile

7. Tunnel Interface

8. FlexVPN Client Profile

Enable AAA

Unlike the server we are less likely to need multiple policies on the client so in this instance we just change the defaltone.

aaa new-modelaaa authorization network default local

Define the local subnets to be encrypted

ip access-list standard permit



Create the IKEv2 Keyring

crypto ikev2 keyring peer address

pre-shared-key psk

Create the IKEv2 Authorization Policy

crypto ikev2 authorization policy route set access-list route set interface

Create the IKEv2 Profile

Same config as the server but instead using the default authorization method list.

crypto ikev2 profile match identity remote address authentication remote pre-shareauthentication local pre-sharekeyring local aaa authorization group psk list default

Create the IPSec Profile

crypto ipsec profile set ikev2-profile

Create the tunnel interface

interface tunnel tunnel mode ipsec ipv4ip address negotiatedtunnel source tunnel destination dynamictunnel protection ipsec profile

Create the FlexVPN Client Profile

crypto ikev2 client flexvpn peer client connect tunnel

TBC

• FlexVPN Hub-And-Spoke



• FlexVPN Spoke-To-Spoke

• FlexVPN Hardware-Based Remote Access

• FlexVPN Software-Based Remote Access

Cisco Group Encrypted Transport VPN (GetVPN)

TBC

GDOI

• Used with MPLS networks to offer confidentiality and integrity services whilst still maintaining the any-to-anyfeature of MPLS

• GDOI is used in GetVPN alongside IPSec to provide the key distribution services between peer in the samegroup.

Site To Site VPNS with Cisco ASA

Implementing Site-To-Site VPNs on Cisco ASA

Basic ASA IKEv1 Site-To-Site VPN ASDM Configuration

Requirements

# Java installed on management PC # Following bootstrap configuration on the ASA

• IP Addressing for management interface

• Routing to management PC

• Username/Password configured

• HTTP Server enabled and acess granted from the Management PC

• ASDM Image copied to ASA Flash and enabled

Configuration

# Start ASDM and login # Select Configuration # Navigate to

Notes

• Normal to receive certificate error when accessing as ASA is using self-signed certificate initially

• Wizard also available, Wizards > VPN Wizards > Site-To-Site VPN Wizard



Basic ASA IKEv1 Site-To-Site VPN CLI Configuration

# Configure Phase 1 Policy ::

• For ASA less than 8.4.1 ::

crypto isakmp policy encryption hash group life-time authentication pre-share

• For later ASA versions ::

crypto ikev1 policy encryption hash group life-time authentication pre-share

# Configure PSK ( ::

• For ASA >= 7.0 and less than 8.4.1 :: tunnel-group type ipsec-l2l tunnel-group ipsec-attributes

pre-shared-key

• For ASA later versions :: tunnel-group type ipsec-l2l tunnel-group ipsec-attributes

ikev1 pre-shared-key

# Enable ISAKMP on the approropriate (e.g. Internet facing) interface :: crypto map interface

# Enable ISAKMP ::

• For ASA less than 8.4.1 :: crypto isakmp enable

• For later ASA versions :: crypto ikev1 enable

Basic ASA IKEv1 VPN with RSA

# Define hostname :: hostname

# Define domain name :: domain-name

# Configure Trusted CA ::

crypto ca trustpoint enrollment url http://

# Download CA certificates and accept them :: crypto ca authentication


http:/


# Enroll with the CA :: crypto ca enroll

# Configure Phase 1 Policy ::

crypto isakmp policy encryption hash group lifetime authentication rsa-sig

# Configure IPSec Transform-Set

• For ASA less than 8.4.1 :: crypto ipsec transform-set

• For later ASA versions :: crypto ipsec ikev1 transform-set

# Configure IPSec Transform-Set (>= v8.4.1)

# Configure IPSec SA Lifetime ::

crypto ipsec security-association lifetime seconds

# Configure Encryption Domain :: access-list permit ip

# Configure Crypto Map :: crypto map match address crypto map set transform-set crypto map set peer ! optional - overridedefalt value crypto map security-association lifetime seconds

# Configure Connection Profile (Tunnel-group> ::

• For ASA less than 8.4.1 :: tunnel-group type ipsec-l2l tunnel-group ipsec-attributes

trustpoint

# Define interfaces on which to accept this VPN connection :: crypto map interface

# Enable ISAKMP ::

• For ASA less than 8.4.1 :: crypto isakmp enable

• For later ASA versions :: crypto ikev1 enable

Based ASA IKEv2 VPN with PSK

# Create IKEv2 Proposal ::

crypto ikev2 policy encryption integrity group lifetime authentication pre-share

# Create IPSEC Transform Set ::

crypto ipsec ike2 ipsec proposal protocol esp integrity protocol esp en-cryption

# Define global IPSec SA Lifetime :: crypto ipsec security-association lifetime seconds

# Define Connection Profile ::

tunnel-group type ipsec-l2l2 ike21 local-authentication pre-shared-key ikev2 remote-authentication pre-shared-key

# Define Encryption Domain :: access-list permit ip



# Crypto map :: crypto map ipsec-isakmp crypto map set ikev2 ipsec-proposal crypto map set peer crypto map match address

# Define interface from which to accept these VPN connections crypto map interface

# Enable IKEv2 on the interface crypto ikev2 enable

Based ASA IKEv2 VPN with PSK

Prequistes

• Ensure hostname is set

• Ensure domain name is set

• Ensure time is correct

Configuration

# Define the Trusted CA ::

crypto ca trustpoint enrollment url http://

# Download CA certificates, verify the given Hash is correct :: crypto ca authenticate

# Request certificate from the CA (Enrollment) :: crypto ca enrol

# Create IKEv2 Proposal ::

crypto ikev2 policy encryption integrity group lifetime authentication rsa-sig

# Create IPSEC Transform Set ::

crypto ipsec ike2 ipsec proposal protocol esp integrity protocol esp en-cryption

# Define global IPSec SA Lifetime :: crypto ipsec security-association lifetime seconds

# Define Connection Profile ::

tunnel-group type ipsec-l2l2 ikev2 local-authentication certificate ikev2 remote-authentication cer-tificate

# Define Encryption Domain :: access-list permit ip

# Crypto map :: crypto map ipsec-isakmp crypto map set ikev2 ipsec-proposal crypto map set peer crypto map set trustpoint crypto map match address

# Define interface from which to accept these VPN connections :: crypto map interface

# Enable IKEv2 on the interface :: crypto ikev2 enable


http:/


ASA VPN setup with IP SLA

# Requirements

• Configure IP SPA

# Configure ICMP SLA ::

sla monitor type echo protocol ipIcmpEcho interface timeout frequency

sla monitor scheudle start-time now life forever

# Check Track Status :: show track

# ISAKMP Policy # PSK

grumpy networkers journal documentation...ing the ike and ipsec sessions within udp (ip protocl 17)...

Documents