VPN: GRE over IPSec

GRE Over IPSec

GRE can do things that IPSec can’t do, and vice versa

IPSec is very secure, but it does have drawbacks. Originally, IPSec couldn’t carry multicast traffic, and you may still run into some trouble with that in the field – the first IOS release that allowed IPSec to carry multicast traffic was 12.2(4)T, and there are plenty of routers out there running an earlier IOS.

The latest IOS versions can’t handle all multicast traffic, however. Multicast traffic generated by OSPF and EIGRP can’t be carried by basic IPSec – we’ve got to run a combination of IPSec and GRE, commonly called GRE over IPSec.

By combining GRE and IPSec, each protocol helps to compensate for the other’s limitation:

  • IPSec adds data integrity and confidentiality that GRE does not offer
  • GRE offers the ability to carry routing protocol traffic, which IPSec does not offer.

The GRE encapsulation happens first, and then that encapsulation is encapsulated again, by IPSec. In effect, we have a GRE tunnel inside an IPSec tunnel. Hence the term, GRE Over IPSec.

Cisco’s website recommends the use of transport mode over tunnel mode with GRE over IPSec. Using transport mode results in less total overhead.

High point:  GRE over IPSec allows the transmission of dynamic routing protocol multicast traffic.

Configuration example exported from SDM:

crypto isakmp policy 1
authentication pre-share
encr 3des
hash sha
group 2
lifetime 86400
exit
crypto isakmp key secretkey address 172.31.1.1
crypto ipsec transform-set ESP-3DES-SHA esp-sha-hmac esp-3des
mode tunnel
exit
ip access-list extended SDM_1
remark SDM_ACL Category=4
permit gre host 10.2.1.2 host 172.31.1.1
exit
crypto map SDM_CMAP_1 1 ipsec-isakmp
description Apply the crypto map on the peer router's interface having IP
address 10.2.1.2 that connects to this router.
set transform-set ESP-3DES-SHA
set peer 172.31.1.1
match address SDM_1
set security-association lifetime seconds 3600
set security-association lifetime kilobytes 4608000
exit

After copying that config to the downstream router, apply the crypto map to the physical interface and create a tunnel interface manually:

interface Tunnel0
ip address 10.1.1.2 255.255.255.0
ip mtu 1420
tunnel source FastEthernet0/1
tunnel destination 10.2.1.1

VPN: VPN Configuration Part 2

Here is a really good summary from a training video of most of what is required to setup an IPSec VPN on a Cisco router:

*Screenshot

photo-1

We can see the Phase 1 ISAKMP policy we covered on the previous post, this covering the encryption, hash, authentication method, lifetime and remote peer IP Address.

We can also see the Phase 2 IPSec configuration, mainly being the transform set used and it’s name.

We can also see the Crypto Map configuration, with the remote peer IP address, transform set reference and the ACL it is using to match interesting traffic. ACL 123 is not pictured, but this is simply an Extended ACL with the interesting IP traffic set.

Example:

access-list 123 permit ip 172.10.5.0 0.0.0.255 172.10.1.0 0.0.0.255

One missing piece of configuration is the referencer to the crypto map at an interface level:

R1(config-crypto-map)#interface serial 0/1
R1(config-if)#crypto map CCNP
R1(config-if)#
*Apr 1 17:27:04.807: %CRYPTO-6-ISAKMP_ON_OFF: ISAKMP is ON

When we ping an interesting IP address, the IPSec VPN will be established and we can use this command to see the state of play:

‘show crypto isakmp sa’

R2#show crypto isakmp sa
dst src state conn-id slot status
172.12.123.1 172.12.123.2 QM_IDLE 1 0 ACTIVE

SA States

QM_IDLE is what we do want to see; here are a few other potential messages we don’t want to see, along with a quick explanation of each courtesy of Cisco’s website.

A common error message is MM_NO_STATE, and if you think that sounds bad, you’re right! This indicates a fundamental problem with Phase I, most likely a mismatch of attributes between peers.

MM_KEY_EXCH can indicate a misconfiguration of the peer’s IP address, and this message can also be generated by a misconfigured pre-shared key.

Two other excellent IPSec troubleshooting commands are show crypto map and show crypto ipsec transform-set.

ACL Considerations with VPNs

IPSec protocols use ports that must not be blocked by ACLs:

  • ESP, protocol number 50
  • AH, protocol number 51
  • IKE, UDP port 500

Overview of IPSec Configuration Requirements

  • Created the ISAKMP policy
  • Created the IPSec transform set
  • Defined interesting traffic with the crypto access-list
  • Created the crypto map – AND applied it to the proper interface
  • Made sure our ACLs allowed the appropriate port numbers

VPN: VPN Configuration Part 1

*Big credit to Chris Bryant and his CCNP Study Guide for the majority of the below content.

Configuring Site-to-Site IPSec VPNs

Configuring a site-to-site VPN is basically a five-step process.

  1. Process Initialization via “interesting traffic”
  2. IKE Phase 1 (IKE SA negotiation)
  3. IKE Phase 2 (IPSec SA negotiation)
  4. Data Transfer
  5. Tunnel Termination

IPSec doesn’t just start working by itself – it requires interesting traffic to be sent by a host. This interesting traffic initializes the IPSec process. A crypto access-list will define interesting traffic for our VPN.

IKE Phase I. Assuming we’re running Main mode, there will be six messages overall. The initiator will first transmit proposals for the encryption and authentication schemes to be used. At this point, IKE’s looking for an ISAKMP policy that’s a match at both endpoints.

In the second exchange of IKE Phase I, the devices will exchange Diffie- Hellman public keys; from this point on, the rest of the negotiation is encrypted.

The initiator and recipient authenticate each other in the third exchange of Phase I, using an encrypted form of their IP addresses. The IKE SA is then established and Phase II can begin.

(If we had chosen to run IKE in Aggressive Mode, this would have been a three-message process. )

The initiator packets everything needed for the SA negotiation in the first message, including its Diffie-Hellman public key.

The recipient responds with the acceptable parameters and authentication information, and its Diffie-Hellman public key.

The initiator then sends a confirmation that it received that information, and we’re done.

IKE Phase 2 has one mode, Quick mode. This is also a three-message process. The initiator proposes parameters for the IPSec SA, the recipient responds with a list of acceptable parameters, and the initiator then transmits a message that lets the responder know that message 2 was received and processed. This message is called proof of liveness.

With the IPSec SA in place, the hosts can now exchange data.

Once the data exchange is complete, the tunnel can be torn down. This tunnel termination can be configured to occur after a certain number of bytes have passed through the tunnel, or perhaps after the tunnel have been up for a certain number of seconds.

But what if traffic is flowing through the tunnel at the same time the tunnel’s supposed to be torn down? No fear – a new Security Association can be agreed upon while the existing one is still in place.

Creating An IKE Policy

Before configuring the IKE policy, make sure ISAKMP is enabled with the crypto isakmp enable command. It’s supposed to be on by default, but we all know how that is.

R1(config)#crypto isakmp enable
To display the current IKE policies, run show crypto isakmp policy.
R1#show crypto isakmp policy
Global IKE policy
Default protection suite
encryption algorithm: DES - Data Encryption Standard (56 bit keys).
hash algorithm: Secure Hash Standard
authentication method: Rivest-Shamir-Adleman Signature
Diffie-Hellman group: #1 (768 bit)
lifetime: 86400 seconds, no volume limit

We’re not going to use the default, however. We’ll create a custom policy with the crypto isakmp policy command. Policies can be assigned priorities, as shown below by IOS Help. The lower the number, the higher the priority, with 1 being the highest priority. There is no default.

R1(config)#crypto isakmp policy ?
<1-10000> Priority of protection suite
R1(config)#crypto isakmp policy 100

IOS Help shows the options for the IKE policy.

The options for authentication are preshared keys, RSA Signature, and RSA Encryption. The default is RSA Signature. We’ll configure the policy to use preshared keys.

R1(config-isakmp)#authentication ?
pre-share Pre-Shared Key
rsa-encr Rivest-Shamir-Adleman Encryption
rsa-sig Rivest-Shamir-Adleman Signature
R1(config-isakmp)#authentication pre-share
The options for encryption are DES, AES, and 3DES (TDES). The default is DES. We'll use 3DES.
R1(config-isakmp)#encryption ?
3des Three key triple DES
aes AES - Advanced Encryption Standard.
des DES - Data Encryption Standard (56 bit keys).
R1(config-isakmp)#encryption 3des

We do have options for the Diffie-Hellman group, so we’ll use group 5.

The default is group 1.

R1(config-isakmp)#group ?
1 Diffie-Hellman group 1
2 Diffie-Hellman group 2
5 Diffie-Hellman group 5
R1(config-isakmp)#group

The hash algorithm will be either MD5 or SHA. The default is SHA, so we’ll set the policy to MD5.

R1(config-isakmp)#hash ?
md5 Message Digest 5
sha Secure Hash Standard
R1(config-isakmp)#hash md5

Finally, we need to set the SA lifetime. The default is the maximum number of seconds, 86,400, which equals 24 hours. We’ll set that to 42,400 seconds.

R1(config-isakmp)#lifetime ?
<60-86400> lifetime in seconds
R1(config-isakmp)#lifetime 42400

show crypto isakmp policy displays both policies on the router – the default and the one we just wrote.

Here’s a list of the parameters and what has to happen for successful negotiation.

  • Hash: exact match
  • Encryption: exact match
  • Authentication: exact match
  • DH Group number: exact match
  • Lifetime: Remote peer policy must have lifetime equal to or less than initiator. If less, the lower value is used.

To create a pre shared key:

The crypto isakmp key command does this. Along with the key itself, the IP address of the remote peer must be configured:

‘crypto isakmp key CCNP address 172.16.16.1’

Verification command:

‘show crypto isakmp sa’

Configuring The IPSec Transform Sets

An IPSec Transform Set is simply a group of individual parameters that will enforce a security policy. The endpoints must agree exactly on which encryption and algorithms will be used to create the IPSec SA. If there’s an exact match, the IPSec process continues; if there’s no match, the process is terminated and the session torn down.

As with ISAKMP policies, multiple transform sets can be configured and sent to a remote peer. The remote peer will compare each set received against its own transform sets, and when a match is found, the IPSec SA will be built.

Config:

crypto ipsec transform-set NAMEOFTRANSFORMSET AH or ESP

mode TUNNEL or TRANSPORT

IPSec SA Lifetimes

The default SA lifetime is 1 hour. This is another value that must match to form a VPN.

‘crypto ipsec security-association lifetime seconds 1800’

Interesting Traffic/Crypto Maps

We use an extended access list to highlight interesting traffic. Interesting traffic is what is matched to then trigger the IPSec VPN to life. The logic with these is to match traffic that is destined OUTBOUND, however you can match INBOUND traffic. The reason to match INBOUND is so that you can determine what traffic HASNT been encrypted.

Extended ACL Config Example:

access-list 123 permit ip 172.10.5.0 0.0.0.255 172.10.1.0 0.0.0.255

Crypto Map Configuration Example:

crypto map CCNP 100 ipsec-isakmp

TBC on next video…

VPN: VPN Theory

VPN Theory

To be honest this one is a bit of a snore and away from R&S. I covered a lot of this when I did CCNA Security, however GRE tunnels and site to site VPNS on a router come up on the CCNP and surely will on the CCIE so here we go. (I am going to skip a lot of ‘basic basics’ as they are slightly off topic)

VPNs offer three vital functions. Note that two of these occur at the receiver, and one at the sender.

  1. Data origin authentication allows the receiver to guarantee the source of the packet.
  2. Encryption is just that – the sender encrypts the packets before sending them. If an intruder picks them off the wire, they will have no meaning.
  3. Integrity is the receiver’s ability to ensure that the data was not affected or altered in any fashion as it traveled across the VPN.

There are three different protocols we can use to create this tunnel.

  1. Originally defined in RFC 1701, Generic Routing Encapsulation enables a Cisco router to encapsulate a packet in an IP header. When the packet reaches the remote router, the header is stripped off. GRE’s drawback is that there’s no encryption scheme, and that’s a pretty big drawback.
  2. Defined in RFC 2661, The Layer 2 Tunneling Protocol (L2TP) is actually a hybrid of Microsoft’s Point-to-Point Tunneling Protocol (PPTP) and Cisco’s own Layer 2 Forwarding (L2F). Again, the major drawback is that L2TP doesn’t have an encryption scheme either.
  3. This giant flaw is corrected by IP Security, generally referred to as IPSec. IPSec does offer encryption along with authentication, and that’s why you’ll see more IPSec in today’s networks than L2TP or GRE.

VPN Terminology

Data Confidentiality means that only the devices that should see the data in an unencrypted form will see the data that way. Generally, this is achieved by one endpoint encrypting the data and sending it across the link in that fashion, with the second endpoint unencrypting the data.

Data Integrity means that the recipient of the data can guarantee that the received data is the same as the transmitted data – in short, that the data was not altered during transport.

Data Origin Authentication guarantees that the data originated from a specific endpoint.

Anti-replay protection (sometimes just called “replay protection”) protects against replay attacks, a malicious repeat and/or delay of a valid transmission. (Anti-replay protection can use several different methods of defeating such an attack, including the one-time use of tokens for the proof of identity or by using sequence numbers; a repeated sequence number will be rejected.)

Encryption

Data Encryption Standard (DES). DES was developed in 1976, and a few problems have developed with DES since then. The main issue is that the key used by DES to encrypt data is only 56 bits in size. (A key is a random string of binary digits.) Thirty years ago, that was fine, but then again floppy disks used to be the largest storage unit any of us needed! Depending on which documentation you read, DES keys can be broken in any time frame from 24 hours to ten minutes.

Triple DES (3DES) is just what it sounds like – the DES encryption procedure is run three times, with three different 56-bit DES keys. That’s a total of 168 bits, but the effective security provided is considered to be only 112 bits.

The Advanced Encryption Standard (AES) is being rapidly adopted by governments and organizations around the world. AES can run on any Cisco router that has IPSec DES/3DES capability.

Key Encryption Schemes

Symmetric encryption is an algorithm where the key that is used for encryption is also used for decryption. Symmetric encryption is sometimes called secret key encryption.

Variations of symmetric encryption include stream algorithms, where one bit or byte is encrypted/decrypted at a time, and block algorithms, where blocks of data are encrypted/decrypted as a whole. These data blocks are usually 64 bits in size. Both DES and 3DES use symmetric encryption.

The drawback to symmetric encryption is that the key is used for two purposes, making it that much easier for an intruder to discover the key.

Asymmetric encryption involves two keys for both the sender and receiver. This public key encryption scheme involves a public and private key for each user. Before starting the actual encryption process, the public key should be certified by a third party called a Certificate Authority (CA).

Protecting the keys..

To create the VPN, we need the endpoints to exchange secret keys, but since the VPN doesn’t exist yet, the secret keys must be exchanged over a non-secure connection. The Diffie- Hellman algorithm allows the exchange of secret keys over a non-secure communications channel.

The IPSec Architecture

IPSec is a combination of three following protocols:

  1. Authentication Header (AH), which defines a method for authentication and securing data
  2. Encapsulating Security Payload (ESP), which defines a method for authenticating, securing, and encrypting data
  3. Internet Key Exchange (IKE), which negotiates the security parameters and authentication keys.

AH does offer:

  • data origin authentication
  • data integrity
  • anti-replay protection (optional)

AH does not offer data confidentiality.

The Encapsulating Security Payload (ESP) does just that. ESP offers all of the following:

  • data origin authentication
  • anti-replay protection
  • data confidentiality

Comparing AH vs ESP

ESP is more processor-intensive than AH. If your data does not require data confidentiality, AH may meet all your requirements.

ESP requires strong cryptography, which isn’t available and/or allowed everywhere. AH has no such requirement.

Phew! zzzzzzzzzzz

Extra Reading on VPN Theory

The below is an extract from a previous security article I wrote for a job:

To ensure that the goals of confidentiality, integrity and availability are all met, it is best practice for any VPN solution to follow Cisco best practice IPsec framework standards.

6.1 NEGOTATION

The best practice for establishing a site to site VPN is ESP+AH which offers Authentication/Data Integrity and Encryption.

6.2 ENCRYPTION

The strongest asymmetric encryption algorithm available for data transfer is AES 256Bit.

*A site to site VPN should be configured in TUNNEL mode to ensure that encryption is applied from Layer 3 upwards.

6.3 AUTHENTICATION

The strongest hashing algorithm available for authentication is SHA 160Bit but MD5 128Bit is still a recommended algorithm.

 6.4 KEY EXCHANGE/PROTECTION

The strongest algorithm available for protecting a shared secret key is Diffie Hellman 5. However this is a very intensive level of encryption capable of up to 1536bits of encryption which can cause performance issues with each VPN appliance Therefore the best practice and recommendation is to use DH1 768Bit or DH2 1024Bit. However before a decision is made as to which DH group, the VPN appliance series and version should be reviewed.

 6.5 PRE SHARED KEY/CERTIFICATE

****** currently use a ‘Pre Shared Key’ to establish site to site authentication. This key is protected using Diffie Hellman key exchange.

6.6 TRANSFORM SET

Based on the above recommendations, an example transform set for establishing a site to site VPN should be as follows:

Phase 1 – (ISAKMP) – AES 256 Bit – SHA – PSK – DH2

Phase 2 – (IPSec) – AES 256 Bit – SHA

Lifetime 86400