Step-by-Step: Configuring Route-Based IPsec VPNs on Cisco IOS

As a business evolves from a small local operation into a large enterprise, its technological and security requirements scale rapidly. Opening international branch offices and establishing third-party vendor partnerships mean that users across the globe suddenly need constant, reliable access to centralized servers in the corporate HQ, private data centers, or cloud environments.

Historically, companies relied on dedicated leased lines (like MPLS) to achieve this. However, leased lines are notoriously expensive, slow to provision, and lock businesses into rigid carrier contracts. This is where Site-to-Site VPNs come into play. By leveraging standard, cost-effective internet connections, a Site-to-Site VPN creates a secure, encrypted tunnel over the public internet, allowing remote locations to access corporate resources as if they were physically present on the local network.

In this guide we will look into how to setup a Route-Based VPN which is easier to configure and manage than its legacy counter part Policy-Based VPN between two Cisco Routers.

Scenario

A expanding branch office that connects back to the corporate HQ across a standard Internet Service Provider (ISP) connection. To secure this traffic, we will establish a site-to-site IPsec tunnel between the branch edge router and the HQ core router.

However, this isn't just for corporate internal data. In this specific architecture, the branch router is configured for a full-tunnel deployment—meaning it will use the secure IPsec tunnel to route both local corporate traffic and general internet traffic directly through the HQ network before it hits the web.

To build out and test this lab scenario, we will use a network topology with the following IP address allocation schema (perfect for replicating inside a network simulator like GNS3 or Cisco Packet Tracer):

G0/0: 203.0.113.1/30
G0/1: 10.10.10.1/24
Tunnel0: 10.255.255.1/30

ISP

G0/0: 203.0.113.2/30
G0/1: 198.51.100.2/30
L0: 1.1.1.1/32
L1: 8.8.8.8/32

Branch

G0/0: 198.51.100.1/30
G0/1: 10.20.20.1/24
Tunnel0: 10.255.255.2/30

Step 01: Basic Setup (Hostname & Interface Configuration)

First we will perform all the basic configuration including the hostname and the physical interfaces of all the routers.

HQ Router

enable
configure terminal

hostname HQ

interface g0/0
ip address 203.0.113.1 255.255.255.252
description WAN-LINK
no shutdown
exit

interface g0/1
ip address 10.10.10.1 255.255.255.0
description LAN-Link
no shutdown
exit

ISP Router

enable
configure terminal

hostname ISP

interface g0/0
ip address 203.0.113.2 255.255.255.252
description Link-To-HQ
no shutdown
exit

interface g0/1
ip address 198.51.100.2 255.255.255.252
description Link-To-Branch
no shutdown
exit

Branch Router

enable
configure terminal

hostname Branch

interface g0/0
ip address 198.51.100.1 255.255.255.252
description WAN-LINK
no shutdown
exit

interface g0/1
ip address 10.20.20.1 255.255.255.0
description LAN-Link
no shutdown
exit

Step 02: VTI (Virtual Tunnel Interface) Configuration

This process has three main phases,

Phase 01: Policy & Pre-Shared Key Configuration

A Cisco router can host multiple ISAKMP policies simultaneously. When a router initiates a VPN session, it sends its entire list of configured policies to the remote peer. The receiving device compares this list against its own local policies, searching for a match by evaluating them sequentially, starting from the lowest policy number. Once a matching policy is found, the pre-shared key (PSK) is used to authenticate the two endpoints and establish the secure management tunnel.

Phase 02: Defining Transform set & IPSEC Profile

With the management channel established, Phase 2 dictates exactly how the actual data passing through the tunnel will be protected. We define an IPsec Transform Set to specify our data encryption and integrity algorithms. We then bind this transform set to an IPsec Profile, which acts as a clean, reusable security template that we can map directly to a virtual interface.

Phase 03: Tunnel Creation

This is the definitive step for a route-based VPN. Instead of using legacy crypto maps, we spin up a virtual point-to-point interface called a Virtual Tunnel Interface (VTI). We assign it an IP address, define its physical source and destination endpoints, and apply our IPsec profile. The tunnel immediately encapsulates and encrypts any traffic directed into it by the routing table.

We will go through each phase on both routers HQ, and Branch.

HQ Router

Phase 01:

crypto isakmp policy 10
encryption aes 256
hash sha256
authentication pre-shared
group 14
exit

crypto isakmp key abc@123 destination address 198.51.100.1

Phase 02:

crypto ipsec transform-set VPN_TS esp-aes 256 esp-sha256-hmac
mode tunnel
exit 

crypto ipsec profile VPN_PROFILE
set transform-set VPN_TS
exit

Phase 03:

interface Tunnel1
description VPN_to_Branch
ip address 10.255.255.1 255.255.255.252
tunnel source GigabitEthernet0/0
tunnel destination 198.51.100.1
tunnel mode ipsec ipv4
tunnel protection ipsec profile VPN_PROFILE
exit

Branch Router

Phase 01:

crypto isakmp policy 10
encryption aes 256
hash sha256
authentication pre-shared
group 14
exit

crypto isakmp key abc@123 destination address 203.0.113.1

Phase 02:

crypto ipsec transform-set VPN_TS esp-aes 256 esp-sha256-hmac
mode tunnel
exit 

crypto ipsec profile VPN_PROFILE
set transform-set VPN_TS
exit

Phase 03:

interface Tunnel1
description VPN_to_HQ
ip address 10.255.255.2 255.255.255.252
tunnel source GigabitEthernet0/0
tunnel destination 203.0.113.1
tunnel mode ipsec ipv4
tunnel protection ipsec profile VPN_PROFILE
exit

Step 03: Routing Configuration

Now that the tunnel interfaces are built, we must configure routing so the networks can talk. However, because our objective is to route all branch internet traffic through the HQ via the tunnel, we have to be incredibly careful.

If we simply point a default route (0.0.0.0 0.0.0.0) out the tunnel interface on the Branch router without any preparation, the tunnel will immediately crash. This happens because the router will try to encapsulate the VPN traffic inside the VPN traffic, creating a recursive routing loop.

To prevent this, we must separate our routing into two steps: Underlay Routing (establishing the physical connection) and Overlay Routing (moving the actual traffic).

Mandatory Underlay Routing

Before configuring any corporate network routing, both routers must have an explicit path to reach each other's physical WAN IPs across the internet. These static routes are mandatory to prevent tunnel interface flapping.

HQ Router (Default Gateway)

ip route 0.0.0.0 0.0.0.0 203.0.113.2

Branch Router (Route to HQ)

ip route 203.0.113.1 255.255.255.255 198.51.100.2

This forces the Branch router to always use the physical ISP gateway (198.51.100.2) whenever it talks to the HQ's public IP (203.0.113.1), keeping the underlying IPsec tunnel stable.

Note: Ensure you change the subnet mask to a host-specific /32 or 255.255.255.255 for the remote peer IP so it takes strict priority!

Overlay Routing Configuration

With the underlay configured, the routers treat the tunnel like a direct, private cable. You can now choose how you want to route corporate and internet traffic over that tunnel. Pick Static Route Configuration or Dynamic Route Configuration for your lab.

Option 01: Static Routing

If your topology is simple with a small number of devices and prefer a fixed setup without protocol overhead, use static routing to direct the branch traffic into the tunnel.

HQ Router (Return Route to Branch)

ip route 10.20.20.0 255.255.255.0 tunnel1

Branch Router (Send everything into the Tunnel)

ip route 0.0.0.0 0.0.0.0 tunnel1

Option 02: Dynamic Routing (OSPF)

Because VTIs support multicast, you can completely automate network discovery using OSPF.

HQ Router (Return Route to Branch)

router ospf 1
network 10.10.10.0 0.0.0.255 area 0
network 10.255.255.0 0.0.0.3 area 0
default-information originate always

Note: If you use OSPF, the Branch router will learn routes dynamically, but it still needs to be told to send internet traffic to the HQ. To do this, we inject a default route from the HQ router using the the command default-information originate always above.

Branch Router (Send everything into the Tunnel)

router ospf 1
network 10.20.20.0 0.0.0.255 area 0
network 10.255.255.255.0 0.0.0.3 area 0

Step 04: Network Address Translation (NAT) Configuration

Because public Internet Service Providers (ISPs) strictly drop private RFC 1918 IP addresses, any traffic originating from our internal networks must be translated into a routable public IP address before exiting to the web. In a standard network, the HQ router only needs to hide its local LAN (10.1.1.0/24) behind its public WAN IP. However, because our Branch router is forwarding all of its internet traffic through the IPsec tunnel, the HQ router must also perform NAT on behalf of the Branch LAN (10.2.2.0/24). To configure this on the HQ Router, we will follow the following steps.

Define "Inside" and "Outside" interfaces.
Define relevant IP address ranges in an ACL
Enable Port Address Translation (PAT).

Define NAT Zones (Inside/Outside interfaces)

interface GigabitEthernet0/1
ip nat inside

interface Tunnel1
ip nat inside

interface GigabitEthernet0/0
ip nat outside

Create the NAT Access-List

Next, we build a standard ACL that defines exactly which subnets are allowed to be translated. We will include both the HQ corporate LAN and the incoming Branch LAN.

ip access-list standard NAT_TRAFFIC
permit 10.10.10.0 0.0.0.255
permit 10.20.20.0 0.0.0.255

Enable Port Address Translation (PAT)

Finally, we bind the ACL to the public-facing WAN interface (GigabitEthernet0/0). The overload keyword ensures that hundreds of internal users from both sites can share the single public IP address simultaneously.

ip nat inside source list NAT_TRAFFIC interface GigabitEthernet0/0 overload

With this final step complete, a user sitting at the Branch office can open a web browser, their traffic will be securely encrypted, sent across the internet via the VTI, decrypted at the HQ, translated to the HQ's public IP, and successfully sent out to the global internet!

Step 05: Testing & Verification

With the configurations applied, the underlay routes secured, and the NAT policies in place, it is time to test the entire deployment end-to-end.

Configure and Verify Local Gateways

Before checking the status of the VPN tunnel, ensure your end-host Virtual PCs (if you are utilizing a lab environment like GNS3) have local IP addresses assigned and can successfully reach their respective local default gateways.

HQ VPC

ip 10.20.20.5 255.255.255.0 10.20.20.1

Branch VPC

ip 10.20.20.5 255.255.255.0 10.20.20.1

From here, you can execute a ping 10.10.10.5 from the Branch PC to confirm that secure, cross-site corporate communication is flowing smoothly through the VTI, followed by a ping to 8.8.8.8 to ensure your full-tunnel NAT configuration is operating flawlessly!

Troubleshooting Issues

Issue 01: The IPsec Tunnel Fails to Form (Phase 1 or Phase 2 Down)

Potential Causes:

Pre-Shared Key Mismatch: The keys configured on HQ and Branch do not match exactly (remember, Cisco PSKs are case-sensitive!).
ISAKMP Policy Mismatch: One router is expecting an algorithm that the other isn't offering. The Hash, Encryption, Diffie-Hellman Group, or Authentication methods must be identical on both peers.
Wrong IP Target Definition: The IP address specified in your crypto isakmp key command does not match the actual incoming interface IP of the remote peer.

Troubleshooting:

First, verify the health of your management tunnel by running the following command on both endpoints:

show crypto isakmp sa

If the output is completely blank or the state is stuck in MM_NO_STATE, Phase 1 has failed. To isolate the mismatch, inspect your configured ISAKMP parameters side-by-side using:

show crypto isakmp policy

Finally, verify that your pre-shared keys and peer IP definitions are perfectly accurate by pulling the crypto portion of your active configuration:

show running-config | section crypto

Issue 02: Tunnel1 Keeps Flapping (Constantly Cycling Up and Down)

Potential Causes:

Underlay Routing Loop: You forgot to configure the host-specific /32 static route on the Branch router pointing to the HQ's public WAN IP, or you pointed your underlay routing path into the tunnel itself. The router is attempting to encapsulate the outer VPN transport packets inside the inner encrypted tunnel.

Troubleshooting:

Check your Branch router's routing table:

show ip route

Ensure you see an explicit, static host route pointing directly to the HQ router's public IP via the physical ISP gateway IP in addition to the default route via Tunnel1 as show in the screenshot.

Alternatively, the fastest way to isolate this is to perform a direct host lookup for the HQ's public IP using this targeted command:

show ip route 203.0.113.1

Analyze the output carefully. The active path to reach 203.0.113.1 must explicitly point out your physical WAN interface via the ISP's public gateway IP, not via Tunnel1. If it points to the tunnel, your underlay route is missing or overridden!

Issue 03: Missing OSPF Routes

If your tunnel interface shows up / up and you can ping across the tunnel IPs, but some of your OSPF routes are missing or OSPF won't peer at all, you might have one of the following issues.

Potential Causes:

Incorrect OSPF Network Statements: The network statement or wildcard masks under OSPF AS number do not accurately encompass the actual IP addresses of physical and tunnel interfaces.
Interface IP Configuration Error: The interfaces are misconfigured or are not sitting in the same exact subnet block.

Troubleshooting:

First, check whether your routers are even attempting to build an adjacency by running:

show ip ospf neighbor

If the output is completely empty, it means no OSPF relationship is forming. To find out why, verify that your OSPF process is actively running and check which networks it is tracking by executing:

show ip protocols

Look closely at the output. Ensure you see a line stating "Routing Protocol is ospf 1" (confirming the process is active), and then inspect the "Routing for Networks:" section. Verify that your interface subnets are accurately matched against your wildcard masks.

If the OSPF protocol configurations are accurate but the peering is still dead, double-check your physical and virtual interface IP addresses using these two commands:

show ip interface brief

show running-config | section interface

Issue 04: Branch Can't Access Internet

If corporate cross-site communication works beautifully but your branch users get a timeout whenever they try to load an external website, your traffic is getting lost at the edge.

Potential Causes:

Missing NAT Zone Definition: You forgot to apply the ip nat inside command directly onto the HQ's interface Tunnel0. If the HQ router doesn't recognize the tunnel as an inside security zone, it will forward the raw private branch packets directly to the ISP without translating them, resulting in an immediate drop.
NAT ACL Exclusion: Your standard access-list on the HQ router (NAT_TRAFFIC) does not explicitly permit the Branch LAN subnet (10.20.20.0/24).

Troubleshooting:

First, log into the HQ router and check if active Network Address Translations are occurring for the branch subnet while a branch end-host attempts to ping a public internet IP:

show ip nat translations

If the output is completely empty or only shows local HQ translations, you need to verify your interface zone assignments. Run the following command on the HQ router:

show ip nat statistics

Analyze the output and look specifically for the "Outside interfaces:" and "Inside interfaces:" listings. Verify that both your physical LAN interface (Gig0/1) and your virtual tunnel interface (Tunnel1) are explicitly listed under the inside interface section.

If your interfaces are mapped correctly, the culprit is your traffic classification. Inspect your active access-lists to ensure the branch subnet is allowed:

If the Tunnel interface is found under "Inside Interfaces:" section, then verify the ACL configuration next using the following command.

show ip access-lists

Confirm that a lines states permit 10.20.20.0 0.0.0.255. If it's missing, update the ACL to resolve the issue!

Migrating from legacy, policy-based crypto maps to a modern Route-Based IPsec VPN using VTIs provides an immediate architectural advantage for an expanding enterprise network. By treating the secure tunnel as a standard routed interface, you eliminate the complexity of mirror-image ACLs and pave the way for seamless scalability.

Throughout this guide, we successfully backhauled all branch traffic through our corporate infrastructure. Managing a full-tunnel scenario requires a strict adherence to configuration dependencies:

Stabilizing the Underlay: Ensuring explicit physical paths exist between the public WAN endpoints prevents dangerous routing loops and tunnel flapping.
Abstracting the Overlay: Leveraging VTIs allows you to seamlessly layer static routing or dynamic protocols like OSPF over the encrypted framework.
Unifying Edge Security: Applying a clear NAT zone policy at the corporate hub ensures that remote branches are safely translated before hitting the public internet.

With your configuration verified and a robust troubleshooting matrix in hand, you are fully equipped to deploy, manage, and maintain a high-performance site-to-site fabric capable of supporting your business as it scales globally.