LAB 1 - BASIC VPNS INTEGRATION IPSEC VPN SITE-TO-SITE

Welcome to part one of my modules. In this chapter you will be learning how to integrate a network with a static IP address (IPSEC NAT). Since the creation of computer networking, there has always been a need to interconnect private networks. This is beneficial for users and computers to access or share resources.

In order to protect Virtual Private Networks IPsec is a protocol which is used to secure the transmission of data, video and voice. These secure tunnels are built using public network infrastructure such as the internet. This is achieved by the protocol employing advance algorithms, in return providing the user with confidentiality of the data that has been transmitted through the internet.

The goal of the chapter is to arm the user on how to configure and implement routers to create a permanent secure site-to-site VPN tunnel.

Equipment Used

MacBook Air Retina 13" 2019 for labs

Dell Alienware M15 R5 Ryzen Series 9 Edition for labs

Dell Precision T5610 ESXI Host

QNAP TS-932 iSCSI (VM Storage 40TB)

QNAP TS-869 Pro iSCSI (VM Storage 56TB)

Cisco ASA 5515-X (x2)

Cisco 1941 (x2)

Cisco 3750 XR (x2) (10G Module)

Sophos XG Firewall

Access Point Ubiquiti

Surfboard S33 (Modem)

Terminal Emulator: ZOC 8

EVE NG PRO

IOS Virtual Routers from Cisco VIRL2 subscription

Start

Encryption is achieved by using the IPsec protocol in tandem with the tunnels. The Internet Security Association & Key Management Protocol ISAKMP with IPsec are essential for building and encrypting VPN tunnels. ISAKMP is also referred to as Internet Key Exchange is a negation protocol, which allows Routers, Firewalls, to agree on how to build an IPsec Security Association.

Security Association can be defined as the following: -

Security association is a description of how two or more entities will use security services in the context of a particular security protocol (AH or ESP) to communicate securely on behalf of a particular data flow.

It includes such things as the transform and the shared secret keys to be used for protecting the traffic.

The IPsec security association is established either by IKE or by manual user configuration.

Security associations (IPSEC) are unidirectional and are unique per security protocol.

When Security Associations are established for IPsec, the security associations (for each protocol) for both directions are established at the same time. This means that there exists one SA for each direction of traffic flow.

When using IKE to establish the security associations for the data flow, the security associations are established when needed and expire after a period of time (or volume of traffic).

If the security associations are manually established, they are established as soon as the necessary configuration is completed and do not expire. The IKE Security Associations (SAs) are bi- directional.

“

As defined within RFC2408 ISAKMP negotiations are broken down into two phases: -

1. In Phase 1 each client (router) creates the first tunnel which protects later ISAKMP negotiation messages.

2. In Phase 2 another tunnel is created to protects data.

IPsec is then used to encrypt exchanged data between the two routers (Site-to-Site). This is achieved by employing advanced encryption algorithms, which in turn gives users authentication, encryption, and critical anti-replay packet protection.

Lab 1

Basic site-to-site IPsec VPN

Figure 1: Lab 1 Basic site-to-site IPsec VPN

Note:- Basic routing has been established prior to the configuration of this lab, if you would like to follow along routing must be established before proceeding, which can be achieved statically, or dynamically dealers choice.

Lab Tasks

Configure an IPsec VPN tunnel from R1 to R2 using the following policy shown below.

ISAKMP Policy 
IPsec Policy
Authentication: Pre-Shared
Encryption: ESP-3DES
Hash: MD5
Hash: ESP-MD5-HMAC
DH Group: 2
Proxy-ID/Crypto ACL 10.1.1.1 -   10.2.2.2 vice-versa
Encryption: 3DES
PSK: cisco111, cisco222

Note: -

Reachability is achieved only through the loopback interfaces “lo0”.

R1
10.1.1.0/24
R2
10.2.2.0/24
R3
10.3.3.0/24
R4
10.4.4.0/24

ISAKMP is defined in RFC 7296 and covers the following aspects: -

^ Procedure to authenticate a communicating peer

^ How to create and manage security associations (SA)

^ Key generation techniques

^ Threat mitigation, such as DOS and replay attacks.

^ UDP 500 is the transport for phase 1 tunnel

Note: -

“IKE does not allude to any details of key management or key exchange, and it’s not associated with any key-generation techniques. Cisco uses OAKLEY for the key exchange protocol, within their security products.

What is OAKLEY?

OAKLEY enables the user to select between different and well established Diffie-Hellman groups. Not all DH groups are supported on Cisco devices, Cisco currently support DH groups 1, 2, 5, 14, 15, 16, 19, 20, 21, 24

Please look at table for a further breakdown of the DH Groups.

Diffie-Hellman Group 1
768 bit
Diffie-Hellman Group 2
1024 bit
Diffie-Hellman Group 5
1536 bit
Diffie-Hellman Group 14
2048 bit
Diffie-Hellman Group 15
3072 bit
Diffie-Hellman Group 16
4096 bit
Diffie-Hellman Group 19
256 bit ECP
Diffie-Hellman Group 20
384 bit ECP
Diffie-Hellman Group 21
512 bit ECP
Diffie-Hellman Group 24
2048 bit, 256 bit   subgroup

KEK or PSK - Key Encryption Key - Used to encrypt the key for the first tunnel.

Phase 1 - ISAKMP Protocol

Phase 2 - ESP Protocol

ISAKMP and OAKLEY create an authenticated, secure tunnel between R1 and R2. The two routers then negotiate the SA for IPsec. In order to establish a tunnel R1 and R2 must authenticate with one another and establish a shared key.

In IOS three authentication methods are available to the user, RSA signatures (PKI), RSA encrypted pseudorandom numbers (nonces) and a pre-shared key (PSK), the option we will be implementing in this lab. DH is used by both Routers to agree upon a common session key.

IPsec uses a different shared key from the first tunnel ISAKMP and OAKLEY. The IPsec shared key can be derived by using DH again to ensure Perfect Forward Secrecy, or by refreshing the shares secret derived from the first DH exchange.

Before the IPsec tunnel is created both Routers need to identify its global peer address.

IKE Phase 1: The two ISAKMP peers establish a secure and authenticated channel. This channel is known as the ISAKMP SA. ISAKMP has two modes Main Mode, and Aggressive.

IKE Phase 2: SAs are negotiated on behalf of service such as IPsec that need keying material. This phase is also referred to as Quick Mode.

In order to configure IKE Phase 1, the reader needs to configure ISAKMP policies. Cisco IOS allows the user to create multiple polices with different configuration statements, which allows multiple peers or routers to negotiate different polices.

Next, we will be configuring Phase 1, Building the ISAKMP policy on both routers.

Lab Implementation

ISAKMP Policy 10 (R1-R2 tunnel)

Network Device R1
    Commands Used:
        en
        config t
        crypto isakmp policy 10
        encryption 3des
        hash md5
        authentication pre-share 
        group 2

ISAKMP Policy 10 (R1-R3 tunnel)

Network Device R1
    Commands Used:
        en
        config t
        crypto isakmp policy 30
        encryption aes
        authentication pre-share 
        group 14

Next, we need to define two pre-shared keys locally on the routers, this is done using the following command. Please note that this must match on both sides to establish a tunnel

Pre-Shared Keys: -

crypto isakmp key cisco111 address 192.1.20.2 #R2
crypto isakmp key cisco222 address 192.1.30.3 #R3

This concludes the IKE Phase 1 configuration for establishing the first tunnel.

Next, we will be configuring Phase 2 where we will be defining the transform-set which specifies the hashing, the security protocol and the encryption used in Phase 2.

As we are establishing a VPN with two routers in this lab R1-R2 and R1-R3 we are creating two different transform-sets as the VPN policy requirements are different for Phase 2. This is achieved by building two transform-sets and giving them an individual name.

! Phase 2 used between R1-R2
crypto ipsec transform-set TSET esp-3des esp-md5-hmac
 mode tunnel

! Phase 2 used between R1-R3
crypto ipsec transform-set TSET1 esp-aes esp-sha-hmac
 mode tunnel

Now that Phase 2 has been configured, we need to define a crypto ACL or proxy ID which defines interesting traffic. This interesting traffic is between the loopback networks on R1-R2, and R1-R3. This is achieved by building an access-list permitting the loopback networks earlier built.

access-list 101 permit ip 10.1.1.0 0.0.0.255 10.2.2.0 0.0.0.255 log-input
access-list 103 permit ip 10.1.1.0 0.0.0.255 10.3.3.0 0.0.0.255 log-input 

Note I like to log the input as it shows me if my ACLs are a hit or not, when generating defined traffic.

The final steps for configuring R1 is to tie all this configuration to a crypto map. Cisco IOS offers three choices to the user when configuring a crypto map.

IPsec-ISAKMP: This is the best option; it tells the system to use ISAKMP to encrypt and decrypt the key.

IPsec-Manual: This is considered to be the worse choice a user could use. This allows the key to be entered manually on both ends!

GDOI: This choice is used for GETVPN configuration and is the abbreviation of Group Domain of Interpretation.

In this lab we will be using the first option earlier defined IPsec-ISAKMP to build our crypto map.

Building a Crypto Map on R1

Network Device R1
    Commands Used:
        en
        config t
        crypto map CMAP 5 ipsec-isakmp 
        set peer 192.1.20.2 (R1-R2)
        set transform-set TSET
        match address 101
        crypto map CMAP 30 ipsec-isakmp 
        set peer 192.1.30.3 (R1-R3)
        set transform-set TSET1
        match address 103

Note: - Cisco hardware limitation

Above we have one crypto map for two different VPN polices, as we can only apply one crypto map per one physical interface.

The last step for R1 is to apply the crypto map to the outbound interface facing the peer. For the purposes of this lab this will be the interface facing R4 the ISP Internet Router.

To apply the crypto map to the interface, use the following command under the interface configuration mode.

interface GigabitEthernet0/0
 crypto map CMAP

! Save Configuration
wr mem

Configuration R2

Building ISAKMP Policy on R2

Network Device R2
    Commands Used:
        en
        config t
        crypto isakmp policy 10
        encryption 3des
        hash md5
        authentication pre-share 
        group 2

Next, we need to define one pre-shared key locally on the router, this is done using the following command. Please note that this must match on both sides to establish a tunnel.

Pre-Shared Keys: -

crypto isakmp key cisco111 address 192.1.10.1

This concludes the IKE Phase 1 configuration for establishing the first tunnel.

Next, we will be configuring Phase 2 where we will be defining the transform-set which specifies the hashing, the security protocol and the encryption used in Phase 2.

! Phase 2 used between R2-R1
crypto ipsec transform-set TSET esp-3des esp-md5-hmac
 mode tunnel

Now that Phase 2 has been configured, we need to define a crypto ACL or proxy ID which defines interesting traffic. This interesting traffic is between the loopback networks on R2-R1. This is achieved by building an access-list permitting the loopback networks earlier built.

access-list 101 permit ip 10.2.2.0 0.0.0.255 10.1.1.0 0.0.0.255

Building a Crypto Map on R2

Network Device R2
    Commands Used:
        en
        config t
        crypto map CMAP 5 ipsec-isakmp 
        set peer 192.1.10.1 (R2-R1)
        set transform-set TSET
        match address 101

The last step for R2 is to apply the crypto map to the outbound interface facing the peer. For the purposes of this lab this will be the interface facing R4 the ISP Internet Router.

To apply the crypto map to the interface, use the following command under the interface configuration mode.

interface GigabitEthernet0/1
 crypto map CMAP

Configuration R3

Building ISAKMP Policy on R3

Network Device R3
    Commands Used:
        en
        config t
        crypto isakmp policy 30
        encryption aes
        authentication pre-share 
        group 14

Next, we need to define one pre-shared key locally on the router, this is done using the following command. Please note that this must match on both sides to establish a tunnel. R1 & R3 Policies need to be the same as well as the pre-shared key.

Pre-Shared Keys: -

crypto isakmp key cisco222 address 192.1.10.1

This concludes the IKE Phase 1 configuration for establishing the first tunnel.

Next, we will be configuring Phase 2 where we will be defining the transform-set which specifies the hashing, the security protocol and the encryption used in Phase 2.

! Phase 2 used between R3-R1
crypto ipsec transform-set TSET esp-aes esp-sha-hmac
 mode tunnel

Now that Phase 2 has been configured, we need to define a crypto ACL or proxy ID which defines interesting traffic. This interesting traffic is between the loopback networks on R2-R1. This is achieved by building an access-list permitting the loopback networks earlier built.

access-list 101 permit ip 10.3.3.0 0.0.0.255 10.1.1.0 0.0.0.255

Building a Crypto Map on R3

Network Device R3
    Commands Used:
        en
        config t
        crypto map CMAP 5 ipsec-isakmp 
        set peer 192.1.10.1 (R3-R1)
        set transform-set TSET
        match address 101
        

Next, we need to apply the crypto map to the outbound internet facing interface, in this lab this will be the interface facing R4, acting as the Internet ISP.

interface GigabitEthernet0/2

crypto map CMAP

This concludes R3 configuration, next we will test and verify the configuration, starting on R1, working our way to R2, and finally R3.

PROOF IS IN THE PUDDING!

Testing & Verifying

First, we will look at both policies we have recently configured on R1, policy 10, 30.

Command Used: -

R1 # show crypto isakmp policy 

From this command we can view both the polices we built earlier, note these need to match on both ends in order for the tunnels to establish.

Next, we can view and verify the pre-shared key using the following command.

As we can see from the output two pre-shared keys have been defined for two different peering addresses.

Now we can test the configuration.

In order to see the ISAKMP process I suggest turning on the debug commands just to see the process when interesting traffic has been defined.

Commands used:

R1 # debug crypto isakmp

R1 # debug crypto ipsec

! Define interesting traffic

R1 # ping 10.2.2.2 source 10.1.1.1

Now let's test the 2nd tunnel which is R1 <-> R3

! Define interesting traffic

R1 # ping 10.2.2.2 source 10.1.1.1

In The Words Of The Late, Great Marvin Gaye, What's Going On?

The first packet triggered R1 ISAKMP process as this match the interesting traffic we earlier defined in the access-list.

Before the R1 starts sending IKE packets to R2, R1 first checks whether there is a local SA matching that traffic, this check is checked against the IPSec SA not the IKE SA.

From the debug logs we can clearly see the outbound and remote IP addresses, port number, local proxy and remote proxy. The protocol used in Phase 2 is ESP, we also defined the transform-set to the default mode of tunnel.

Output from interesting traffic from R1 - R2

Note:- If an unprotected packet matches a permit entry in a particular access list associated with an IPSec crypto map entry, that packet is dropped because it was not sent as an IPSec-protected packet (and the router was expecting it to be encrypted as it matches the reverse of the crypto ACL).

IKE Phase 1 Main Mode Message 1 MM1

In Cisco IOS IKE Main Mode is used, so we should expect six packets for Phase 1. The following output shows the reader that the Aggressive Mode cannot start, the reader should also note that this does not mean the router is experiencing errors; this just informs the user that Aggressive Mode is not configured on the local router, see output below from debug logs.

Next the R1 checks for the configured ISAKMP policy and notices that pre-shared key authentication is configured. R1 has to check if there is a key configured for R2 it’s configured peer.

All things going well the first IKE packet is sent to R2 using the configured peer address, on UDP 500.

The interesting traffic which we triggered from the ping we executed earlier will cause R1 to use the ISAKMP Policy we earlier defined. The pre-shared key for the remote peer is found, which indicates that ISAKMP will use the pre-shared key to authenticate with R2. This is done in the final stages of the IKE Phase 1.

Within the security industry the router initiating the IKE exchange is referred to as the “initiator”, and for the purposes of this lab, R1 will be our initiator as this is were we executed the ping. R2 will be called the responder. R1 has sent it’s configured ISAKMP policy along with vendor-specific IDs which are part of the IKE packet payload.

MM_NO_STATE:- Indicates that ISAKMP SA has been created, but nothing else has happened yet.

IKE Phase 1 Main Mode Message 2 MM2

Currently the Phase 1 process is going as desired, R1 has received a response packet from R2, however this is one area that can go wrong when establishing a tunnel.

The packet that was sent to R2 contains the SA chosen by R1 and other useful information such as vendor IDs. These vendor specific fields are used to determine if network address translation (NAT) is being used, and to maintain keep-alives. R2 matches the ISAKMP policy from the received packet from R1 to the ISAKMP policy locally configured.

In this lab this is isakmp policy 10, if there is a match with policies then the tunnel establishment process can continue.

If there is a mismatch in policy the crosscheck will fail, resulting in the tunnel being down.

R1 is now processing ISAKMP parameters that have been sent by our responder R2. The vendor IDs are processed to determine if R2 supports the NAT-Traversal, Dead Peer Detection feature. ISAKMP policy is checked against the local policy we earlier configured. The att are acceptable messages indicating that both devices R1 and R2 policies match with each other. This is a good thing!

The reader can see from the output that the lifetime timer has been started, which is set at the default value of 86,400 seconds. This lifetime is for the ISAKMP SA, not the IPSec SA, which have their own parameters.

IKE Phase 1 Main Mode Message 3 MM3

In the third message for Phase 1, R1 transmits key-exchange information for the Diffie-Hellman DH secure key-exchange process.

1. The DH process starts with each peer generating a large prime integer, p and q. Each peer sends the other its prime integer over the insecure channel. For example, Peer A sends p to Peer B. Each peer uses the p and q values to generate g, a primitive root of p.

2. Each peer generates a private DH key (peer A: Xa, peer B: Xb).

3. Each peer generates a public DH key. The local private key is combined with the prime number p and the primitive root g in each peer to generate a public key, Ya for peer A and Yb for peer B. The formula for peer A is Ya =g^Xa mod p. The formula for peer B is Yb =g^Xb mod p. The exponentiation is computationally expensive. The ^ character denotes exponentiation (g to the Xa power); mod denotes modulus.

4. The public keys Ya and Yb are exchanged in public.

5. Each peer generates a shared secret number (ZZ) by combining the public key received from the opposite peer with its own private key. The formula for peer A is ZZ=(YbXa ) mod p. The formula for peer B is ZZ=(YaXb ) mod p. The ZZ values are identical in each peer. Anyone who knows p or g, or the DH public keys, cannot guess or easily calculate the shared secret value, largely because of the difficulty in factoring large prime numbers.

6. Shared secret number ZZ is used in the derivation of the encryption and authentication symmetrical keys.

See below for R1 output for Message 3.

IKE Phase 1 Main Mode Message 4 MM4

The forth message contains the KE payload, and based on this information both R1, and R2 can generate a common session key which is used to secure further communications. The pre-shared key earlier configured on both routers is used for this calculation. Once this message has been received from its peer the router can now determine if NAT is being used along the path.

IKE Phase 1 Main Mode Message 5 MM5

The firth message in this lengthy process is used for transmitting authentication information to R2. This transmitted information is protected by the common secret derived from the key process in Message 3.

MM_KEY_EXCH - indicates that the R1 and R2 have exchanged DH public keys and have generated a shared secret. ISAKMP SA currently remain unauthenticated, the process of authentication has now just started.

IKE Phase 1 Main Mode Message 6 MM6

R1 and R2 identities have now been verified by each routers and the SA that have been established. This final message finished ISAKMP Main Mode Phase 1 resulting in a change of status to IKE_PROCESS_COMPLETE.

IKE Phase 2 QUICK MODE Message 1

Now that Phase 1 is complete, the next process the routers encounter is Quick Mode. The routers send out packets containing local proxy IDs which are network/host addresses to be protected by the IPSec tunnel, and the security policy earlier defined using the transform set name TSET.

The state of the IKE is QM_IDLE. This indicates to the user that the ISAKMP SA is idle. It currently remains authenticated with its peer R2 and can now be used for subsequent Quick Mode exchange.

The routers are currently negotiating parameters for the IPSec tunnel which will be used for data traffic transmission. These parameters were defined earlier within the transform-set command used earlier. The logs show that the attr are acceptable, meaning that the IPSec parameters defined in the transform-set named TSET matches on R1 and R2.

The crypto logs above show the reader that the local and remote proxies have been matched 10.1.1.1 & 10.2.2.2 loopback interfaces respectively. This was defined from access-list 101 which was configured earlier and then applied to the crypto map called CMAP.

The IPSec have now been created and inserted into the routers’s security association database commonly referred to as SADB, the DB meaning DataBase. SA’s are identified by the Security Parameter Index SPI values, which allows a user to differentiate many different tunnels terminated on the same router, two SPI values are generated for one tunnel, respectively one SPI for the inbound SA and one SPI for the outbound SA.

The SPI value commonly a hex number is inserted into the ESP header for packets exiting the router. At the other side R2 in this lab of the tunnel the SPI value inserted into the ESP header enables R2 to reach parameters and keys that have been dynamically agreed upon during the earlier IKE negotiations, or session key refreshment, such as a lifetime timeout.

Lastly we are going to show the SPI’s and how they match from using the “show crypto ipsec sa”. We will performing this verification on both ends to show the reader that the SPI values stated earlier should match.

show crypto ipsec sa

The first time I ran this command I notices that there was no SPI values in the command used above, this would indicate that no interesting traffic has been flowing over the tunnel and the tunnel expired. Re-running the ping command refreshed the tunnel, and showed the corresponding SPI values.

R1

R2

"The Outbound SPI for R1 should match the Inbound SPI for R2"

Read that last statement twice and confirm command output.

The Inbound SPI for R1 should match the Outbound SPI for R2.

Again read that last statement twice and confirm command output.

Give yourself a pat on the back you just completed the first lab towards your CCIE Security.