🚧 Site under development – content may change

  • January 18, 2025
  • Written by: naxslabs
  • No Comments

Introduction

In today’s interconnected business environment, organizations frequently need to securely transmit sensitive data between geographically distributed locations. Industries handling protected health information (PHI) under HIPAA regulations or payment card data under PCI-DSS standards require robust encryption mechanisms to ensure data confidentiality and integrity during transit across public networks.

IPsec (Internet Protocol Security) provides a comprehensive framework for securing IP communications through authentication, integrity checking, and encryption. This article demonstrates the configuration of a site-to-site IPsec VPN tunnel between two Cisco routers, creating a secure communication channel that meets stringent compliance requirements.

Compliance and Security Context

HIPAA Requirements

Healthcare organizations transmitting PHI must implement technical safeguards including:

  • Encryption of data in transit
  • Access controls and authentication
  • Audit logging capabilities
  • Network security measures

PCI-DSS Requirements

Organizations handling cardholder data must comply with requirements such as:

  • Strong encryption protocols for data transmission over public networks
  • Secure network architecture with proper segmentation
  • Regular security testing and monitoring
  • Restricted access to cardholder data

IPsec addresses these requirements by providing end-to-end encryption, mutual authentication, and secure key exchange mechanisms.

Lab Environment Overview

This configuration uses EVE-NG (Emulated Virtual Environment – Next Generation) to simulate a real-world network topology. EVE-NG is an invaluable tool for network engineers and security professionals, allowing comprehensive testing of complex network scenarios without physical hardware constraints.

Network Topology

Site A Network: 192.168.10.0/24
Site A PCI-DSS Device: 192.168.10.10

Site B Network: 192.168.20.0/24
Site B PCI-DSS Device: 192.168.20.21

Site A WAN Interface: 203.0.113.1/30
Site B WAN Interface: 203.0.114.1/30

The objective is to encrypt sensitive data traversing an unprotected network between SV1 and SV2, such as the internet. To save time, routing has been preconfigured. You can find the configuration files for this lab in the Git repository, which may be helpful if you’re studying for the CCNA or simply interested in IPSec configuration. At this stage, we have confirmed there is reachability between Site A’s router and Site B’s router.

Note that in the Wireshark image above, we can see the ICMP echo request and reply messages between Site A and Site B. Once IPSec is configured, the nature of the traffic will be unknown to anyone potentially sniffing the traffic. Before establishing the tunnel, you would first identify the interesting traffic. For this example, we have chosen subnets 192.168.10.0/24 at Site A and 192.168.20.0/24 at Site B. Any data transferred between these networks will go through the IPSec tunnel.

ISAKMP/IKE Phase 1


The Internet Security Association and Key Management Protocol (ISAKMP) and Internet Key Exchange (IKE) are sometimes used interchangeably when referring to Phase 1 of the tunnel. In short, they establish the initial relationship between the two endpoints (routers, firewalls), including encryption, hashing algorithms, pre-shared keys, certificates, and lifetime. Phase 1 does not cover how the data is protected inside the tunnel; instead, it establishes the tunnel itself. The configuration must match at both ends of the tunnel, Site A and Site B.

Site A Phase 1 Policy

This is our first tunnel, so we have numbered our policy starting with 1. From there, we have chosen AES for encryption, SHA-256 for hashing, Diffie-Hellman Group 2 for key exchange, set the lifetime for 86400 seconds, and configured a pre-shared key of NAXSLABS with the peer address of Site B’s IP address. You may want to try newer and more secure settings, such as the Diffie-Hellman group and certificates instead of a pre-shared key. Just make sure the settings match on both endpoints.

Site A Access List

We also need an access list to control which devices or networks use the tunnel – this is the interesting traffic. This access list instructs the tunnel to allow any devices on the 192.168.10.0/24 network to traverse the tunnel when attempting to reach the 192.168.20.0/24 network. You can’t see the 1 because of screen wrapping, but it is there. We’ve given the ACL the name NAXSLABSVPN-ACL and will use it again shortly.

Phase 2

Phase 2 is where we configure how the data going through the tunnel is protected, such as the encryption protocol (ESP, AH), the algorithm, transport or tunnel mode, etc. Cisco calls this a transform set. A transform set gets attached to a crypto map, and the crypto map gets attached to an interface. Lets have a look at it.

We’ve named the transform set NAXSLABSTS for simplicity and have chosen ESP-AES for encryption and SHA-256-HMAC for message integrity, although there are several options available. Next, we need a crypto map, which essentially bundles the transform set, the peer address, and the ACL we created earlier together. The crypto map is then attached to Site A’s outgoing interface, Ethernet 0/1, in our example.

The configuration for Site A is complete, and you can apply the same configuration to Site B, adjusting only the peer addresses and ACL rules as needed. Once complete, we see that when network 192.168.10.0/24 communicates with 192.168.20.0/24 and vice versa, the traffic is encrypted. We don’t know that it is a simple ICMP request; we only see that the two sites are communicating over an encrypted channel.

In closing out, remember to exclude any networks using the tunnel from NAT translation. One subnet was used for each site in this example, but typically, there will be more, and you will need to modify your NAT ACL accordingly. Finally, this process will be very similar regardless of the device. In fact, most next-generation firewalls make it much easier.

Leave a Reply

Your email address will not be published. Required fields are marked *