Try   HackMD
VPN Configuration

Overview

To secure network traffic between sites and users, organizations use virtual private networks (VPNs) to create end-to-end private network connections. VPNs are private in that traffic over a VPN is encrypted to keep the data confidential while it is transported across a public network.

The first types of VPNs were strictly IP tunnels that did not include authentication or encryption of the data. For example, Generic Routing Encapsulation (GRE), which does not include encryption services, is used to encapsulate IPv4 and IPv6 traffic inside an IP tunnel to create a virtual point-to-point link.

VPN Topologies

VPNs are commonly deployed in one of the following configurations:

Site-to-Site

A site-to-site VPN is created when VPN terminating devices, also called VPN gateways, are preconfigured with information to establish a secure tunnel. VPN traffic is only encrypted between these devices. Internal hosts have no knowledge that a VPN is being used.

Remote-Access

A remote-access VPN is dynamically created to establish a secure connection between a client and a VPN terminating device. For example, a remote access SSL VPN is used when you check your banking information online.

There are two ways to that an end-user may dynamically intiate a Remote-Access VPN:

Clientless Connection

The connection is secured using a web browser SSL connection. SSL is mostly used to protect HTTP traffic (HTTPS) and email protocols such as IMAP and POP3. For example, HTTPS is actually HTTP using an SSL tunnel. The SSL connection is first established, and then HTTP data is exchanged over the connection.

Client-based Connection

VPN client software such as Cisco AnyConnect Secure Mobility Client must be installed on the remote user’s end device. Users must initiate the VPN connection using the VPN client and then authenticate to the destination VPN gateway. When remote users are authenticated, they have access to corporate files and applications. The VPN client software encrypts the traffic using IPsec or SSL and forwards it over the internet to the destination VPN gateway.

VPN Security

The type of VPN method implemented is based on the access requirements of the users and the organization’s IT processes. If support and ease of deployment are the primary issues, consider SSL-based VPNs. When security is an issue, IPsec is the superior choice.

It is important to understand that IPsec VPNs and SSL VPNs are not mutually exclusive. Instead, they are complementary; both technologies solve different problems, and an organization may implement IPsec, SSL, or both, depending on the needs of its telecommuters.

SSL

SSL connections use the public key infrastructure and digital certificates to authenticate peers.

When a client negotiates an SSL VPN connection with the VPN gateway, it actually connects using Transport Layer Security (TLS). TLS is the newer version of SSL and is sometimes expressed as SSL/TLS. However, both terms are often used interchangeably.

Site-to-Site IPsec

Site-to-site VPNs are used to connect networks across untrusted networks such as the internet. In a site-to-site VPN, end hosts send and receive normal unencrypted TCP/IP traffic through a VPN-terminating device, typically called a VPN gateway.

The VPN gateway encapsulates and encrypts outbound traffic. It then sends the traffic through a VPN tunnel over the internet to a VPN gateway at the target site. Upon receipt, the receiving VPN gateway strips the headers, decrypts the content, and relays the packet toward the target host inside its private network.

Site-to-site VPNs are typically created and secured using IP security (IPsec).

The IPsec Framework

IPsec is an IETF standard (RFC 2401-2412) that defines how a VPN can be secured across IP networks. IPsec protects and authenticates IP packets between source and destination. IPsec can protect traffic from Layer 4 through Layer 7.

IPsec is not bound to any specific rules for secure communications. This flexibility of the framework allows IPsec to easily integrate new security technologies without updating the existing IPsec standards. In the diagram below, the currently available technologies are aligned to their specific security functions. The open slots shown in the framework can be filled with any of the choices that are available for that IPsec function, to create a unique security association (SA).

An SA is the basic building block of IPsec. When establishing a VPN link, the peers must share the same SA to negotiate key exchange parameters, establish a shared key, authenticate each other, and negotiate the encryption parameters.

Image Not Showing Possible Reasons
  • The image was uploaded to a note which you don't have access to
  • The note which the image was originally uploaded to has been deleted
Learn More →

IPsec Protocol Encapsulations

Choosing the IPsec protocol encapsulation is the first building block of the framework. IPsec encapsulates packets using Authentication Header (AH) or Encapsulation Security Protocol (ESP). The choice of AH or ESP establishes which other building blocks are available.

Image Not Showing Possible Reasons
  • The image was uploaded to a note which you don't have access to
  • The note which the image was originally uploaded to has been deleted
Learn More →

In IPv4, AH and ESP are IP protocol headers. IPv6 uses the extension headers with a next-header value of 50 for ESP and 51 for AH.

Authentication Header (AH)

AH uses IP protocol 51 and is appropriate only where confidentiality is not required. AH provides data authentication and integrity, but does not provide data confidentiality. The AH encapsulation function is applied to the entire packet, except for any IP header fields that normally change in transit.

AH confirms message integrity by applying a keyed one-way hash function to the packet to create a message digest. The message hash is combined with the text and is transmitted in plaintext. The receiver then confirms message integrity by recalculating the same one-way hash function on the received packets (minus the attached message digest), and comparing the attached and calculated hashes.

With AH authenticity is assured, because the one-way hash also employs a shared secret key between the two systems.

AH supports MD5 and SHA algorithms. AH may not work if the environment uses NAT.

Encapsulation Security Protocol (ESP)

ESP uses IP protocol 50 and provides both Confidentiality, by performing encryption on the IP packet, and Authentication, for the inner IP packet and ESP header. Authentication provides non-repudiation and data integrity verification. Although encryption and authentication are each optional in ESP, at least one of them must be selected.

When both authentication and encryption are selected, encryption is performed first. One reason for this order of processing is that it facilitates rapid detection and rejection of replayed or bogus packets by the receiving device. Prior to decrypting the packet, the receiver can authenticate inbound packets. By doing this, it can quickly detect problems and potentially reduce the impact of DoS attacks.

Optionally, ESP can also enforce anti-replay protection. Anti-replay protection verifies that each packet is unique and not duplicated, by keeping track of packet sequence numbers and using a sliding window on the destination end. This protection ensures that a hacker cannot insert modified packets into the data stream. Anti-replay protection is not supported in AH.

Transport Mode vs Tunnel Mode

ESP and AH can each be applied to IP packets in transport mode or in tunnel mode.

Transport Mode

In transport mode, security is provided only for the transport layer and above, of the OSI model. Transport mode encrypts the payload of the packet but leaves the original IP address in plaintext, which is then used to route the packet through the internet.

AH transport mode provides authentication and integrity for the entire packet. It does not encrypt the data, but it is protected from modification.

ESP transport mode is used between hosts.

Tunnel Mode

In tunnel mode, security is provided for the complete IP packet. The original IP packet is encrypted, then is encapsulated in another IP packet. This is known as IP-in-IP encryption. The outer IP address is used to route the packet through the internet.

AH tunnel mode encapsulates the IP packet with an Authentication Header and a new IP header, and signs the entire packet for integrity and authentication. It does not encrypt the data.

ESP tunnel mode is used between a host and a security gateway, or between two security gateways.

For host-to-gateway applications, if the home router does not support ESP Tunnel Mode, an IPsec client running on the PC performs the IPsec IP-in-IP encapsulation and encryption.

For gateway-to-gateway applications, it is easier to have the security gateways perform the IP-in-IP encryption and encapsulation.

Packet Encryption

The encryption algorithm chosen for the IPsec framework determines the resilience and confidentiality of the connection.

The encryption algorithms highlighted in the figure are all symmetric key cryptosystems.

Data Integrity Verification

Because VPN data is transported over the public internet, a method of proving data integrity is required to guarantee that the content has not been altered. The Hashed Message Authentication Code (HMAC) guarantees the integrity of the message using an algorithmically derived signature-hash.

The figure highlights the two most common HMAC algorithms.

SHA-1 is considered a legacy algorithm. SHA-256 or above is recommended for current data integrity needs.

Access Authentication Mode

Devices on either end of a VPN tunnel must be authenticated before the communication path is considered secure.

The figure highlights the two peer authentication methods.

  • pre-shared secret key (PSK) uses authentication codes entered into each peer manually. PSKs are easy to configure, but do not scale well, because each IPsec peer must be configured with the PSK of every other peer with which it wishes to communicate.
  • Rivest, Shamir, and Adleman (RSA) uses digital certificates (public/private key pairs) to authenticate peers. Each gateway must authenticate its opposite before their tunnel is considered secure.

Key Exchange

Symmetric encryption algorithms require a shared secret key to perform encryption and decryption. The easiest key exchange method is to use a public key exchange method, such as Diffie-Hellman (DH).

DH provides a way for two peers to establish a shared secret key that only they know, even when communicating over an insecure channel.

Variations of the DH key exchange are specified as DH groups:

  • DH groups 1, 2, and 5 — should no longer be used. These groups support a key size of 768 bits, 1024 bits, and 1536 bits, respectively.
  • DH groups 14, 15, and 16 — use larger key sizes with 2048 bits, 3072 bits, and 4096 bits, respectively, and are recommended for use until 2030.
  • DH groups 19, 20, 21 and 24 — with respective key sizes of 256 bits, 384 bits, 521 bits, and 2048 bits support Elliptical Curve Cryptography (ECC), which reduces the time needed to generate keys.

The DH group you choose must be strong enough to protect the IPsec keys during negotiation.

  • If you choose AES 128-bit key, use DH group 14, 19, 20 or 24.
  • If you choose AES-256 or higher, use the DH group 21 or 24.

IKE Protocol

The Internet Key Exchange (IKE) protocol is a key management protocol standard. IKE is used in conjunction with the IPsec standard, and enhances IPsec communcation by adding features and simplifying IPsec configuration.

IKE automatically negotiates IPsec security associations and enables IPsec secure communications between two remote peers.

Instead of transmitting keys directly across a network, IKE calculates shared keys based on the exchange of a series of data packets. This disables a third party from decrypting the keys even if the third party captured all of the exchanged data that was used to calculate the keys. IKE uses UDP port 500 to exchange IKE information between the security gateways.

Key Negotiation Phases

IKE uses the Internet Security Association Key Management Protocol (ISAKMP) framework for phase 1 and phase 2 of key negotiation. Phase 1 negotiates a security association (a key) between two IKE peers. The key negotiated in phase 1 enables IKE peers to communicate securely in phase 2. During phase 2 negotiation, IKE establishes keys (security associations) for other applications, such as IPsec.

Phase 1 – Tunnel Initation

The basic purpose of Phase 1 is to negotiate ISAKMP policy, authenticate the peers, and set up a secure tunnel between the peers. This tunnel will then be used in Phase 2 to negotiate the IPsec policy.

Phase 1 can be implemented in main mode or aggressive mode. When main mode is used, the identities of the two IKE peers are hidden. Aggressive mode takes less time than main mode to negotiate keys between peers. However, since the authentication hash is sent unencrypted before the tunnel is established, aggressive mode is vulnerable to brute-force attacks.

Phase 2 – SA Negotiation

The purpose of IKE Phase 2 is to negotiate the IPsec security association (SA) that will be used to secure communcation across the IPsec tunnel. IKE Phase 2 is called quick mode and can only occur after IKE has established a secure tunnel in Phase 1.

Quick mode also renegotiates a new IPsec SA when the IPsec SA lifetime expires.

The SAs that IPsec uses are unidirectional; therefore, a separate key exchange is required for each data flow.

IKE version 2 is an enhancement of the IKE protocol. Version 2 supports NAT detection and NAT Traversal (NAT-T) during Phase 1 negotiation. If both VPN devices are NAT-T capable, and if they detect that they are connecting to each other through a NAT device, NAT-T is auto detected and auto negotiated. NAT-T encapsulates ESP packets inside UDP and assigns both the Source and Destination ports as 4500. Now ESP packets can traverse NAT.

IPsec VPN Configuration (Site-to-Site)

Implementing a site-to-site VPN requires configuring settings for both IKE Phase 1 and Phase 2. In the phase 1 configuration, the two sites are configured with the necessary ISAKMP security associations to ensure that an ISAKMP tunnel can be created. In the phase 2 configuration, the two sites are configured with the IPsec security associations to ensure that an IPsec tunnel is created within the ISAKMP tunnel. Both tunnels will be created only when interesting traffic is detected.

The steps for IPsec VPN configuration are as follows:

Step 1 – Confirm ACLs

Confirm that any existing ACLs do not block traffic necessary for IPsec negotiations. The ACL commands to permit ISAKMP, ESP, and AH traffic are shown here:

Router(config)# ip access-list extended {name}
Router(config-ext-nacl)# permit udp {source} {mask} {destination} {mask} eq isakmp
Router(config-ext-nacl)# permit esp {source} {mask} {destination} {mask}
Router(config-ext-nacl)# permit ahp {source} {mask} {destination} {mask}

Step 2 – ISAKMP Policy

The next step is to configure the ISAKMP policy for IKE Phase 1. The ISAKMP policy lists the SAs that the router is willing to use to establish the IKE Phase 1 tunnel. The Cisco IOS comes with default ISAKMP policies already in place.

To view the default policies, enter the show crypto isakmp default policy command:

R1# show crypto isakmp default policy 
! 
! Default IKE policy
! Default protection suite of priority 65507
!     encryption algorithm:   AES - Advanced Encryption Standard (128 bit keys).
!     hash algorithm:         Secure Hash Standard
!     authentication method:  Rivest-Shamir-Adleman Signature
!     Diffie-Hellman group:   #5 (1536 bit)
!     lifetime:               86400 seconds, no volume limit
!
!  <...output truncated...>
! 
R1#

Configure the ISAKMP Policy

To configure an ISAKMP policy, use the crypto isakmp policy priority global configuration command. This will enter the ISAKMP policy sub-configuration mode.

Peers will attempt to negotiate using the policy with the lowest number (highest priority). Peers do not require matching priority numbers.

When in ISAKMP policy sub-configuration mode, the SAs for the IKE Phase 1 tunnel can be configured.

R1(config)# crypto isakmp policy 1
R1(config-isakmp)# encryption aes 256
R1(config-isakmp)# hash sha
R1(config-isakmp)# authentication pre-share
R1(config-isakmp)# group 24
R1(config-isakmp)# lifetime 3600
R1(config-isakmp)# end
R1# 
R1# show crypto isakmp policy 
! 
! Global IKE policy
! Protection suite of priority 1
!      encryption algorithm:   AES - Advanced Encryption Standard (256 bit keys).
!      hash algorithm:         Secure Hash Standard
!      authentication method:  Pre-Shared Key
!      Diffie-Hellman group:   #24 (2048 bit, 256 bit subgroup)
!      lifetime:               3600 seconds, no volume limit
! 
R1#

There are five ISAKMP policy values that can be configured:

  1. Hash — hash algorithm used to sign the ISAKMP-tunnel traffic.
  2. Authentication — authentication method for the ISAKMP tunnel.
  3. Group — Diffie-Hellman group to be used for ISAKMP key exchange.
  4. Lifetime — lifespan of this ISAKMP security association.
  5. Encryption — encryption algorithm used to encode the ISAKMP-tunnel traffic.

Define Interesting Traffic

Although the ISAKMP policy for the IKE Phase 1 tunnel is configured, the tunnel does not yet exist. Interesting traffic must be detected before IKE Phase 1 negotiations can begin. Interesting traffic consists of any permitted communications between site-to-site peers.

To define interesting traffic, configure each peer with an ACL to permit acceptable traffic from the local LAN to the remote LAN. The ACL will be used in the crypto map configuration to specify what traffic will trigger the start of IKE Phase 1.

Configure Pre-Shared Key (optional)

Some ISAKMP policy implementations may require that a pre-shared key be used for authentication between site-to-site peers. In this case, the administrator can manually configure a key association for a given peer:

Router(config)# crypto isakmp key <keystring> address <peer-address>
Router(config)# crypto isakmp key <keystring> hostname <peer-hostname>

Step 3 – Configure IPsec Policy

The third step is to configure the set of encryption and hashing algorithms that will be used to transform the data sent through the IPsec tunnel. This is called the transform set. During IKE Phase 2 negotiations, the peers agree on the IPsec transform set to be used for protecting interesting traffic.

Configure a transform set using the crypto ipsec transform-set command. After the transform set is named, the encryption (cipher) and hashing (auth) algorithm can be configured:

R1(config)# crypto ipsec transform-set <name> <cipher> <auth> 
R1(config)#

Step 4 – Configure Crypto Maps

Once interesting traffic is defined, and an IPsec transform set is configured, it is time to bind those configurations with the rest of the IPsec policy in a crypto map.

The following command will enter the crypto map sub-configuration mode:

Router(config)# crypto map <name> <num> { ipsec-isakmp | ipsec-manual }

The sequence number is important when configuring multiple crypto map entries.

Use the crypto map name seq-num command without any keyword to modify the existing crypto map entry or profile.

Create the Crypto Map

To define a crypto configuration, complete the following tasks:

  1. Bind the ACL to the map: match address ACL-identifier
  2. Bind the transform set: set transform-set transform-name
  3. Specify the VPN peer’s IP address: set peer address
  4. Configure the DH group: set pfs group{#}
  5. Configure the IPsec security-association lifetime: set security-association lifetime seconds lifespan
R1(config)# crypto map R1-R2_MAP 10 ipsec-isakmp
R1(config-crypto-map)# match address 101 
R1(config-crypto-map)# set transform-set R1-R2
R1(config-crypto-map)# set peer 172.30.2.2
R1(config-crypto-map)# set pfs group24
R1(config-crypto-map)# set security-association lifetime seconds 900 
R1(config-crypto-map)# exit
R1(config)#

Apply the Crypto Map

To apply the crypto map, enter interface configuration mode for the outbound interface and configure the crypto map map-name command.

R1(config)# interface serial0/0/0
R1(config-if)# crypto map R1-R2_MAP
R1(config-if)#
! *Mar 19 19:36:36.273: %CRYPTO-6-ISAKMP_ON_OFF: ISAKMP is ON
R1(config-if)#

Verify the Map

Use the show crypto map command to verify the crypto map configuration

R1# show crypto map
! Crypto Map IPv4 "R1-R2_MAP" 10 ipsec-isakmp
!     Peer = 172.30.2.2
!     Extended IP access list 101
!         access-list 101 permit ip 10.0.1.0 0.0.0.255 192.168.1.0 0.0.0.255
!     Security association lifetime: 4608000 kilobytes/900 seconds
!     DH group:  group24
!     Mixed-mode : Disabled
!     Transform sets={ 
!             R1-R2:  { esp-aes esp-sha-hmac  } , 
!     }
!     Interfaces using crypto map R1-R2_MAP:
!             Serial0/0/0
!
R1#

Step 5 – Verify IPsec Tunnel

Once both the ISAKMP and IPsec policies are configured, and the crypto map is applied to the appropriate outbound interfaces, test the IKE Phase 1 and Phase 2 tunnels by sending interesting traffic across the link.

R1# ping 192.168.1.1 source 10.0.1.1
!  Type escape sequence to abort. 
!  Sending 5, 100-byte ICMP Echos to 192.168.1.1, timeout !  is 2 seconds: 
!  Packet sent with a source address of 10.0.1.1  
!  .!!!! 
!  Success rate is 80 percent (4/5), round-trip !  min/avg/max = 1/2/4 ms 
R1#

Sending interesting traffic does not guarantee that the tunnels are established. To fully verify that the tunnels have been established, use the show crypto isakmp sa and show crypto ipsec sa commands.

R1# show crypto isakmp sa 
! IPv4 Crypto ISAKMP SA
! dst          src           state      conn-id status
! 172.30.2.2   172.30.2.1    QM_IDLE       1005 ACTIVE
! 
! IPv6 Crypto ISAKMP SA 
! 
R1#
R1# show crypto ipsec sa
! 
! interface: Serial0/0/0
!     Crypto map tag: R1-R2_MAP, local addr 172.30.2.1
!
! <...output truncated...>
! 
!    current_peer 172.30.2.2 port 500
!      PERMIT, flags={origin_is_acl,}
!     #pkts encaps: 4, #pkts encrypt: 4, #pkts digest: 4
!     #pkts decaps: 4, #pkts decrypt: 4, #pkts verify: 4
!     #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
! 
! <...output truncated...>
R1#

Handling Broadcast and Multicast Traffic

IPsec only supports unicast traffic. To enable broadcast or multicast traffic, such as routing protocol packets, the peers in a site-to-site IPsec VPN implementation need to be configured with a Generic Routing Encapsulation (GRE) tunnel for the multicast traffic.

GRE supports multiprotocol tunneling. It can encapsulate multiple OSI Layer 3 protocol packet types inside an IP tunnel. Adding an additional GRE header between the payload and the tunneling IP header provides the multiprotocol functionality. GRE also supports IP multicast tunneling. Routing protocols that are used across the tunnel enable dynamic exchange of routing information in the virtual network. GRE does not provide encryption.

Last changed by 
 
Faelin Landy
0
828

Read more

Ruby on Rails Tutorial, pt. 1 – Ruby

Overview of the "Ruby" part of Ruby on Rails

Jan 25, 2024
ASA Firewall Configuration

ASA Firewall Configuration [toc] --- Getting Started ASA CLI Overview The ASA command line interface has a similar look and feel to the Cisco router IOS. However, the ASA CLI also has different commands. This table contrasts common IOS router and ASA commands.

Nov 21, 2021
Network Security Configuration

Network Security Configuration [toc] --- {%hackmd r8ZvM3noSwKf-NviH6Qb3Q %} Dynamic Routing Protocol Security Routing systems can be attacked by disrupting peer network routers, or by falsifying or spoofing the information carried within the routing protocols. Spoofing routing information may generally be used to cause systems to misinform each other, cause a DoS attack, or cause traffic to follow a path it would not normally follow.

Nov 21, 2021
Network Traffic Control

Network Traffic Control [toc] --- Network Access Management using AAA AAA network security services provide the primary framework to set up access control on a network device. Network and administrative AAA security in the Cisco environment has three functional components: Authentication, Authorization, and Accounting Authentication AAA Authentication can be used to authenticate users for administrative access or it can be used to authenticate users for remote network access. Authentication can be established using username and password combinations, challenge and response questions, token cards, and other methods.

Nov 17, 2021
Read more from Faelin Landy
Published on HackMD