How IPsec Site-to-Site VPN Tunnels Work

Quick Definition: Internet Protocol Security, commonly known as IPsec is a method of encrypting packets that makes VPNs possible. Using a suite of protocols, IPsec can authenticate and encrypt data passing over Internet Protocol networks.

An Overview of IPsec Site-to-Site Tunneling [VIDEO]

In this video, CBT Nuggets trainer Keith Barker covers how to build and verify an IPSec site-to-site tunnel using virtual tunnel interfaces. He walks through all of the elements you need to set up the tunnel, beginning with the theory behind it and then demonstrates a step-by-step configuration.

What is an IPsec Tunnel?

Quick Definition: An IPsec Tunnel not only encrypts and authenticates the packets flowing through it, but it encapsulates each packet into an entirely new one, with a new header. This enables the creation of Virtual Private Networks (VPNs), which depend on IPsec tunnels for network-to-network, host-to-network and host-to-host communications.

What is a Virtual Tunnel Interface?

Quick Definition: A Virtual Tunnel Interface (VTI) is a logical interface supported by Cisco Adaptive Security Appliances (ASAs). A VTI uses IPsec profiles attached to both ends of a tunnel to change the behavior of virtual routing and allows greater flexibility, control and security in creating virtualized networks.

Because IPsec profiles are attached to both ASAs involved in an encrypted transmission, dynamic or static routes can be used. Static crypto access lists do not have to be mapped to interfaces that use VTIs, and remote subnets don't have to be manually tracked and included. All of which is to say that VTIs make deploying and operating VPNs significantly easier.

How to Prepare your Site-to-Site Tunnel: IPsec Necessities

Before establishing a site-to-site tunnel between two ASAs, you'll need to make sure that you have everything you'll need from the IPsec perspective.

First, you'll need an IKE Phase 1 Policy that's compatible on both routers. Here's the one we used in our demonstration:

Global IKE policy
Protection suite of priority 5
Encryption algorithm: AES – Advanced Encryption Standard
Hash algorithm: Secure Hash Standard
Authentication method: Pre-shared Key
Diffie-Hellman group: #14 (2048 bit)
Lifetime: 86,400 seconds, no volume limit

You'll also need a transform set for the IKE phase 2 policies that's compatible on both routers. Here's ours:

Transform set P2P-SET: { esp-256-aes esp-sha-hmac  }
Will negotiate = { Tunnel,  }

Last, you'll need an IPsec profile that can be applied to a tunnel interface:

Crypto ipsec profile P2P-PROFILE
Set transform-set P2P-SET

Site-to-Site Tunnel Preparation: Our Demonstration Network

For our purposes, we'll be imagining a hypothetical network. We're going to create a tunnel between R1 and R3. R1 will be at 10.1.1.0 /24 and connect to the internet on 15.0.0.1. R3 will be at 10.3.3.0 /24 and connect to the internet on 35.0.0.3. Building our site-to-site tunnel will require manually configuring each of those two routers.

How to Prepare your Site-to-Site Tunnel: Tunnel Interface

Before you establish the site-to-site tunnel, there are some configurations you'll need to apply to the tunnel interface itself.

For our demonstration, let's look at our tunnel interface's policies and then break them down line by line:

Interface Tunnel1
ip unnumbered Loopback0
tunnel source Serial1/0
Tunnel mode ipsec 1pv4
Tunnel destination 15.0.0.1
Tunnel protection ipsec profile P2P-PROFILE

First, make sure you specify that you're using IPv4 IPsec mode.

Next, you'll need to either assign a logical IP address or allow the mode to default to IP unnumbered. With IP unnumbered, we simply tell the interface that we're going to go ahead and borrow an IP address that's already on the box. For example, one of your routers may already have 1.1.1.1 as a loopback — and maybe a different one is 3.3.3.3. By using IP unnumbered, we could tell the interface to go ahead and borrow the current IP addresses that are assigned to each of the loopback interfaces respectively.

Also, on this tunnel interface, you'll need to specify a source and destination for a site-to-site static tunnel.

Then, take the IPsec profile that we created above and apply it to each of those tunnel interfaces.

On top of all of that, you're also going to want to run a routing protocol like EIGRP or OSPF in order for R1 to advertise its routes over to R3 and for R3 to dynamically advertise its routes back to R1.

Building an IPsec Site-to-Site Tunnel: Configuring the First Router

First, we'll create a transform set. In our example, we'll be naming our transform set "P2P-set". And we'll use AES-256 for encryption. For data integrity, we'll go ahead and use SHA:

crypto ipsec transform-set P2P-SET esp-aes 256 esp-sha-hmac
exit

Next, we're going to create an IPsec profile that says, "Okay, when this profile is applied to an interface, we want to use the transform set – the one we just created – called P2P-SET":

set transform-set P2P-SET
exit

Presumably, on R1, you would already have an IKE Phase 1 policy configured. But for our purposes here, let's verify what that policy was:

do show crypto isakmp policy

We've already seen that earlier, but let's look again:

Global IKE policy
Protection suite of priority 5
Encryption algorithm: AES – Advanced Encryption Standard
Hash algorithm: Secure Hash Standard
Authentication method: Pre-shared Key
Diffie-Hellman group: #14 (2048 bit)
Lifetime: 86,400 seconds, no volume limit

This tells us that the IKE Phase 1 policy we're using is AES. Also that we're using a pre-shared key for authentication, and SHA for data integrity. It tells us the Diffie-Helman group is #14, and it has a lifetime of 86,400 seconds. Note: Remember that The IKE Phase 1 policy on R1 has to be compatible with the IKE Phase 1 policy on R3.

Next, let's create an interface called Interface Tunnel 1:

interface tunnel 1

This will be our virtual tunnel interface, and we'll specify:

tunnel mode ipsec ipv4

Now, for this tunnel interface, let's use ip unnumbered, effectively telling the ASA that it can go ahead and borrow the IP address on loopback 0:

ip unnumbered loopback 0

We'll specify the source is R1's 15.0.0.1 address, which is its serial 1/0:

tunnel source serial 1/0

Note: For the tunnel's source we could either spell out Serial 1/0 or 15.0.0.1. Either way would be absolutely fine.

We'll also specify that the destination is R3's reachable address of 35.0.0.3:

tunnel destination 35.0.0.3

Last is to apply the IPsec profile that was created earlier, making sure that it's associated with this tunnel interface we've just established:

tunnel protection ipsec profile P2P-PROFILE
exit

Now, regarding our routing protocol, let's instruct the system to make use of EIGRP autonomous system 777:

router eigrp 777

Note: The default method under EIGRP AS 777 for iOS15 is no auto-summary, but to be sure, you can include:

no auto-summary

The last step is to add the network statements for the 10.0.0.0 network and the 1.0.0.0 network:

network 10.0.0.0
network 1.0.0.0
end

And that will include the interface connected to 10.1.1.1 as well as the loopback, which also begins with 1. Because our tunnel interface is borrowing that address, the tunnel interface will also be enabled for EIGRP.

The next step is to head to the other device on our simulated network, R3, and apply a very similar configuration there.

Building an IPsec Site-to-Site Tunnel: Configuring the Second Router

In our example network, the other router we have to prepare for this tunnel is called R3. Begin by entering configuration mode:

conf t

The first step is to create our transformed set:

crypto ipsec transform-set P2P-SET 256 esp-sha-hmac
exit

Note: the actual name doesn't matter very much, but the transforms that we use do have to match exactly what we have on R1.

Next, create an IPsec profile that includes that transformed set. Because our profile is called P2P-PROFILE, and it's going to transform set P2P-SET, those get combined:

crypto ipsec profile P2P-PROFILE
set transform-set P2P-SET
exit

The next step on R3 is to create a tunnel interface:

tunnel mode ipsec ipv4

The R3 interface also has to be told to use IP unnumbered and use the local IP address on loopback 0. Its tunnel source on R3 should be specified, and its destination should be too:

ip unnumbered loopback 0
tunnel source serial 1/0
tunnel destination 15.0.0.1

Note: Remember that on R3, that tunnel destination is the IP address that's reachable at R1.

Still creating the tunnel interface, the last step is to apply the IPsec profile that we created earlier.

tunnel protection ipsec profile P2P-PROFILE
exit

At this point, if everything has gone smoothly, you'll probably get this return:

ISAKMP is ON

Line protocol on Interface Tunnel1, changed state to up

Still on R3, add that the EIGRP routing protocol for autonomous systems 777:

router eigrp 777

Then, include the 10 networks and 3 networks:

network 10.0.0.0
network 3.0.0.0
end

Note: That will include R3's local network of 10.3.3.3 as well as its loopback address.

Once again, if everything has gone correctly, this is when you should see:

EIGRP-IPv4 777: Neighbor 1.1.1.1 (Tunnel1) is up: new adjacency

That's the best sign you could get that the neighborship you're looking to establish has come up between R1 and R3.

Troubleshooting your Site-to-Site Tunnel and VTIs

If you've followed these steps, you should have the connection, tunnel and profiles that you need. But when you create your own and add your own profiles and addresses, you may run into problems and need to identify the culprit. There are a few places you can look for answers to problems.

The first place to check is whether or not the IKE Phase 1 tunnel was ever established. If your end goal is to build an IPsec security association and IKE Phase 1 isn't working, Phase 2 is never going to finalize. Use this command to show whether or not a working IKE Phase 1 tunnel exists:

show crypto isakmp sa

Another useful command will give you a bird's-eye view of the IKE Phase 1 and IKE Phase 2 tunnels that you've got in place. The readout of a small table of the active tunnels can help you see which exist and what their status is:

show crypto engine connection active

In the active connections list, the IKE Phase 1 is likely the bottom result (Type = "IKE"). Meanwhile, the top two (Type = "IPsec") will represent the IPsec tunnel, which is, in fact, two unidirectional tunnels (an inbound and outbound security association) — between R1 and R3.

Rather than assume you got an EIGRP neighborship, you can confirm that one exists:

show ip eigrp neighbors

In addition to that, you can reveal EIGRP-learned routes with:

show ip route eigrp

In the example we've used above, from R3's perspective, you would see the 10.1.1.1 network show up as an EIGRP-learned route. That would be in addition to the loopback address of R1, because it's also included in EIGRP.

Lastly, to verify connectivity, you can perform a ping to 10.1.1.1 (the interface address on R1 on the 10.1.1.1 subnet). By sourcing it from the 10.3.3.3 subnet address, you can verify full connectivity back and forth:

ping 10.1.1.1 source 10.3.3.3

Deploying VPNs With VTIs to Build IPsec Site-to-Site Tunnels

Following these steps should leave you with a site-to-site tunnel between your ASAs, ready to create a peer-to-peer VPN connection. This is a lot to take in all at once, but master this procedure and you'll save yourself all the time and effort that used to be spent managing, configuring, and mapping crypto map access lists.