Module: Network Implementation

Section: Hybrid Connectivity Implementation

Lesson Title: Site-to-Site VPN Configuration

---

Introduction: Bridging the Gap Between Networks

In the modern enterprise landscape, the ability to securely connect geographically dispersed locations is not just a luxury; it is a fundamental requirement. Organizations rarely operate from a single physical location. Whether you are connecting a branch office to a corporate headquarters, or linking an on-premises data center to a public cloud environment like AWS or Azure, you need a reliable method for data to travel across the public internet as if it were a private, dedicated wire. This is where Site-to-Site (S2S) VPNs come into play.

A Site-to-Site VPN acts as a secure, encrypted tunnel between two specific gateways. Unlike a remote-access VPN, which connects an individual user to a network, an S2S VPN connects entire networks together. It allows devices on the local subnet of Site A to communicate with devices on the local subnet of Site B transparently. The traffic is encapsulated, encrypted, and authenticated as it traverses the untrusted public internet, ensuring that sensitive corporate data remains private and protected from eavesdropping or tampering.

Understanding how to configure these tunnels is a critical skill for network engineers and system administrators. If you misconfigure a tunnel, you might find that your latency spikes, your traffic is dropped intermittently, or worse, your organization is exposed to security vulnerabilities. This lesson will guide you through the architectural concepts, the protocol mechanics, the step-by-step configuration, and the industry best practices required to implement a stable and secure Site-to-Site VPN.

---

The Core Components: How S2S VPNs Work

At its heart, a Site-to-Site VPN relies on the IPsec (Internet Protocol Security) suite. IPsec is not a single protocol but a collection of protocols that work together to provide confidentiality, integrity, and authentication. Before we dive into configuration, it is essential to understand the two main phases of an IPsec negotiation.

Internet Key Exchange (IKE)

IKE is the protocol used to set up the security association (SA) in the IPsec suite. It handles the initial authentication, key exchange, and the establishment of the tunnel parameters.

• IKE Phase 1 (Main Mode/Aggressive Mode): This phase establishes a secure, authenticated channel between the two VPN gateways. The goal here is to create a "management tunnel" where the two devices agree on how they will talk to each other securely. They negotiate encryption algorithms (like AES), hashing algorithms (like SHA), and Diffie-Hellman groups.
• IKE Phase 2 (Quick Mode): Once the management tunnel is established, Phase 2 negotiates the actual parameters for the data tunnel. This is where the devices decide which traffic will be encrypted and what specific security protocols will be used to protect the data packets traveling between the two sites.

Callout: Phase 1 vs. Phase 2 Think of Phase 1 as the two diplomats meeting in a secure room to agree on the language and rules of negotiation. Once they have established this secure room (the control plane), Phase 2 is the actual signing of the treaty that governs how they will handle their day-to-day trade (the data plane). Without Phase 1, there is no secure way to establish the rules for Phase 2.

---

Prerequisites for Implementation

Before you open your command-line interface or configuration GUI, you must gather specific information. A lack of preparation is the most common cause of failed VPN deployments. Ensure you have the following details documented for both the Local Site and the Remote Site:

1. Public IP Addresses: Both gateways must have static public IP addresses. If one side uses dynamic addressing, you must use a dynamic DNS service or a VPN type that supports initiator-only connections.
2. Internal Subnets: You need to know the exact IP ranges (CIDR notation) on both sides. The VPN gateway needs to know which traffic should be sent through the tunnel and which should go out to the general internet.
3. Pre-Shared Key (PSK): This is a long, complex string used to authenticate the tunnel. It must be identical on both sides.
4. Encryption and Hashing Standards: Both sides must agree on the same cipher suites. If Site A wants AES-256 and Site B is configured for AES-128, the tunnel will never come up.
5. MTU/MSS Settings: Large packets can sometimes be fragmented, causing performance issues. Knowing your path MTU is vital for tuning.

---

Step-by-Step Configuration: A Practical Example

For this example, we will look at a generic implementation using a command-line approach common to many enterprise-grade routers. We are connecting "Site A" (HQ) to "Site B" (Branch).

Step 1: Define the IKE Policy (Phase 1)

The IKE policy tells the router how to negotiate the initial security handshake.

! Defining the policy for Phase 1
crypto isakmp policy 10
 encr aes 256
 hash sha256
 authentication pre-share
 group 14
 lifetime 86400

• Explanation: We use AES-256 for strong encryption and SHA-256 for data integrity. Group 14 refers to a specific Diffie-Hellman group, which provides a high level of security for the key exchange. The lifetime is set to 86,400 seconds (24 hours).

Step 2: Configure the Pre-Shared Key

This key acts as the password for the tunnel.

! Setting the key for the peer's public IP
crypto isakmp key MyStrongSecretKey123! address 203.0.113.5

• Explanation: The address 203.0.113.5 is the public IP of the remote gateway. Ensure this key is stored in a secure password manager, not in a plain text document.

Step 3: Define the Transform Set (Phase 2)

The transform set defines how the actual user data will be encrypted inside the tunnel.

! Defining the Phase 2 security protocols
crypto ipsec transform-set MY_TRANSFORM_SET esp-aes 256 esp-sha256-hmac
 mode tunnel

• Explanation: We are using ESP (Encapsulating Security Payload) with AES-256 and SHA-256. Tunnel mode is standard for S2S VPNs as it encapsulates the entire original packet.

Step 4: Create an Access Control List (ACL)

The ACL defines the "Interesting Traffic." This is the traffic that triggers the VPN tunnel to come up.

! Traffic from local subnet to remote subnet
access-list 101 permit ip 192.168.1.0 0.0.0.255 10.0.5.0 0.0.0.255

• Explanation: This list tells the router: "If traffic is going from 192.168.1.x to 10.0.5.x, send it through the VPN." Anything else goes to the default gateway (the internet).

Step 5: Configure the Crypto Map

The crypto map ties everything together: the peer, the ACL, and the transform set.

! Binding the VPN components
crypto map MY_VPN_MAP 10 ipsec-isakmp
 set peer 203.0.113.5
 set transform-set MY_TRANSFORM_SET
 match address 101

• Explanation: This map links the specific remote peer to our traffic filter and our encryption methods. Finally, you apply this map to your outside (WAN) interface.

---

Managing MTU and Fragmentation

One of the most frustrating aspects of VPN management is the "black hole" packet issue. Because IPsec adds extra headers to your packets, the overall size of the packet increases. If the packet exceeds the Maximum Transmission Unit (MTU) of the internet path, it will be fragmented or dropped.

If your users report that the VPN connects, but they cannot load web pages or access file shares, it is almost always an MTU issue. You can mitigate this by adjusting the Maximum Segment Size (MSS) on your interfaces.

Tip: Adjusting MSS A common industry standard is to set the TCP MSS to 1350 or 1360 bytes. This leaves enough room for the IPsec overhead while ensuring packets travel through the public internet without being dropped by intermediate routers that have a standard 1500-byte MTU.

---

Best Practices for Secure Implementation

Implementing a VPN is not a "set it and forget it" task. Security is a moving target, and your configuration should reflect the current state of cryptographic standards.

• Disable Legacy Protocols: Never use IKEv1 if IKEv2 is available. IKEv2 is more efficient, handles mobile clients better, and supports stronger encryption suites. Disable support for older, broken protocols like 3DES or MD5.
• Rotate Keys Regularly: Even with strong encryption, rotating your Pre-Shared Keys periodically reduces the impact if a key is ever compromised.
• Implement Dead Peer Detection (DPD): DPD allows your gateway to detect if the remote side has gone silent. If the peer becomes unresponsive, the gateway will tear down the tunnel and attempt to re-establish it, preventing "half-open" states.
• Restrict Access: Your VPN gateway should not be exposed to the entire internet. Use firewall rules to ensure that only the known public IP of the peer can initiate an IKE connection to your gateway.
• Monitor and Log: Use SNMP or Syslog to monitor tunnel status. If a tunnel goes down at 3:00 AM, you want to know about it before the office opens at 8:00 AM.

---

Common Pitfalls and Troubleshooting

Even with careful configuration, things can go wrong. Here are the most frequent issues engineers encounter:

Issue	Likely Cause	Solution
Tunnel stays down	Mismatched PSK or Phase 1 settings	Verify PSK and encryption/hash/DH settings on both sides.
Tunnel is up, but no traffic flows	Mismatched ACLs or Routing	Ensure the interesting traffic ACLs are mirror images of each other.
Traffic drops intermittently	MTU/MSS mismatch	Lower the TCP MSS value on your tunnel interfaces.
Authentication failure	Peer IP mismatch	Ensure the public IP address defined in the peer command is correct.

How to troubleshoot systematically:

1. Check Phase 1 Status: Use the command show crypto isakmp sa. If it says "MM_NO_STATE" or "QM_IDLE," the tunnel is not negotiating correctly.
2. Verify Traffic flow: Use show crypto ipsec sa to see if packets are being "encapsulated" (sent) and "decapsulated" (received). If you see packets being encapsulated but not decapsulated, the remote side is likely not receiving or not processing your traffic.
3. Debug Logs: If all else fails, enable crypto debugging.
   • Warning: Debugging can be CPU-intensive on older routers. Only enable it during a maintenance window and turn it off immediately after gathering the necessary data.

---

Comparing VPN Types

While we have focused on Site-to-Site IPsec VPNs, it is helpful to understand how they fit into the broader networking picture.

• Site-to-Site IPsec: Best for static, permanent connections between two fixed locations. It is highly secure and offers the best performance for large-scale data transfers.
• SSL/TLS VPN: Better for remote access (users at home). It is easier to traverse through firewalls that block non-standard protocols but generally has more overhead than IPsec.
• SD-WAN: A modern approach that manages multiple VPN tunnels across different transport types (broadband, MPLS, LTE) automatically. It is essentially an abstraction layer on top of standard VPN technologies.

Callout: The Case for SD-WAN While manual IPsec configuration is a foundational skill, modern enterprises are moving toward SD-WAN. SD-WAN automates the creation of these tunnels and provides intelligent path selection. However, understanding the underlying IPsec configuration is still necessary for troubleshooting when the automated orchestration fails or when connecting to legacy third-party systems.

---

Security Considerations: Beyond the Tunnel

A VPN tunnel only secures data in transit. It does not provide security for the endpoints themselves. If a server on your local network is compromised, the attacker can use the VPN tunnel to traverse into the remote network.

• Micro-segmentation: Do not allow the entire local subnet to talk to the entire remote subnet. Use firewall rules to restrict traffic to only the specific ports and protocols required (e.g., only allow SQL traffic from the web server to the database).
• Endpoint Protection: Ensure that all devices connected across the VPN have updated antivirus, EDR (Endpoint Detection and Response) agents, and are patched against known vulnerabilities.
• VPN Gateway Hardening: The VPN gateway itself is a high-value target. Ensure the management interface is not accessible from the internet, use multi-factor authentication for administrative access, and keep the firmware updated to patch security vulnerabilities.

---

Step-by-Step: Validating Your Connection

Once you believe the configuration is complete, follow this checklist to validate the implementation:

1. Ping Test: Attempt to ping an internal IP address at the remote site from a device on your local site. If this fails, check your routing table. Does the router know where to send traffic for the remote subnet?
2. Traceroute: Run a traceroute to the remote destination. If the traffic dies at your own default gateway, your ACLs are likely blocking the traffic or the tunnel is not triggering.
3. Encapsulation Counters: Run the show crypto ipsec sa command again. If the count of "pkts encaps" is increasing but "pkts decaps" is zero, the traffic is leaving your site, but the remote site is rejecting it or sending it into a black hole.
4. Security Audit: Verify that your firewall rules are not too permissive. Ensure you aren't accidentally allowing traffic that shouldn't cross the boundary.

---

Advanced Configurations: Redundancy and Failover

In a production environment, a single VPN tunnel is a single point of failure. If the ISP at one site goes down, the tunnel goes down. To achieve higher availability, you should implement redundant VPN tunnels.

• Dual-ISP Redundancy: If your site has two internet connections, you can configure two tunnels—one over each ISP. You can then use routing protocols like BGP (Border Gateway Protocol) or static routes with tracking objects to automatically fail over to the secondary tunnel if the primary one drops.
• Route-Based VPNs (VTI): Instead of using crypto maps (policy-based), you can use Virtual Tunnel Interfaces (VTI). A VTI acts like a physical interface. You can assign an IP address to the tunnel interface and use standard routing protocols like OSPF or BGP to route traffic through the tunnel. This is significantly easier to manage and scale than policy-based VPNs.

Note: VTI vs. Crypto Map Policy-based VPNs (Crypto Maps) are the traditional way to do S2S VPNs. They are rigid and rely on ACLs to define traffic. Route-based VPNs (VTI) represent the traffic as a logical interface. VTI is generally preferred in modern network designs because it allows for cleaner routing tables and better support for dynamic routing protocols.

---

Common Questions (FAQ)

Q: Can I connect two routers with different vendors? A: Yes, IPsec is an industry standard. As long as both devices support the same IKE versions, encryption algorithms, and hashing methods, they should interoperate. However, keep in mind that vendor-specific features (like proprietary NAT-traversal implementations) might require extra tweaking.

Q: Why is my VPN tunnel flapping (constantly going up and down)? A: This is usually caused by an IKE lifetime mismatch or a keepalive issue. If one side thinks the tunnel should expire in one hour and the other thinks it should expire in eight hours, the tunnel will tear itself down periodically. Ensure all lifetime settings match exactly.

Q: Does the VPN encrypt the traffic header or just the payload? A: In standard Tunnel Mode, the entire original IP packet (header and payload) is encrypted and encapsulated within a new IP packet. This hides the internal IP addressing of your network from the public internet.

Q: What is NAT-Traversal (NAT-T)? A: NAT-T is a mechanism used when one or both of the VPN gateways are behind a NAT device (like a home router). IPsec traditionally has trouble with NAT because it modifies packet headers. NAT-T wraps the IPsec packets in UDP port 4500, allowing them to pass through NAT devices without being corrupted.

---

Conclusion and Key Takeaways

Configuring a Site-to-Site VPN is a fundamental exercise in balancing security and connectivity. It requires a meticulous approach to detail, a solid understanding of the IPsec protocol suite, and a proactive mindset toward monitoring and troubleshooting. While the process can be complex, following a structured methodology—from planning and documentation to testing and redundancy—will ensure that your organization remains connected and secure.

Key Takeaways:

1. Preparation is Paramount: Never attempt to configure a VPN without a pre-documented plan that includes public IPs, internal subnets, and agreed-upon encryption standards.
2. Understand the Phases: Remember that IKE Phase 1 establishes the secure management channel, while Phase 2 governs the actual transport of your data. Both must be perfectly aligned between peers.
3. Manage Your MTU: Always account for the overhead of IPsec headers. If your users experience "black hole" traffic issues, adjusting the TCP MSS is often the quickest and most effective fix.
4. Prioritize Modern Standards: Always prefer IKEv2 over IKEv1 and use strong cryptographic suites (AES-256/SHA-256). Avoid legacy, insecure protocols at all costs.
5. Design for Availability: If your network connectivity is business-critical, plan for redundancy. Use VTI-based tunnels and dynamic routing to allow for automatic failover between multiple internet paths.
6. Security Does Not End at the Tunnel: A VPN is a transport mechanism, not a firewall. Always apply strict access control lists and maintain robust endpoint security to prevent threats from traversing the tunnel.
7. Systematic Troubleshooting: When things go wrong, use a logical process: verify Phase 1, check traffic selectors (ACLs), inspect encapsulation counters, and check your routing tables. Never rely on guesswork.

By mastering these concepts, you transition from simply "making the tunnel work" to building a professional, reliable, and secure infrastructure that supports the needs of your organization. Keep your configurations clean, your documentation updated, and your security posture proactive.