Site-to-Site VPNs - Part 1: The Basics

I've been getting a lot of questions lately about VPNs (virtual private networks); how they work, what are they, how to configure them. To most CCNA graduates it can be a bit confusing. Seeing as more than half the work in our NOC consists of VPN-related issues I thought it'd be good to get everything out in the open for those who aren't sure about them.

There are a couple different types of VPN connections (L2L, RAS, SSL, etc), however we're going to just with the basics and cover a site-to-site connection.

If you have your CCNA, you should be familiar with the concept of Frame-Relay. It allows two private networks to connect to one another as if there was nothing but a router in between. Nowadays we generally use MPLS or VPNs in place of a Frame-Relay PVC. What this allows you to do is more easily and dynamically connect multiple subnetworks together for very cheap (and in VPN cases, basically free - provided you have the equipment).

Speaking of equipment, we'll be covering three in these posts: a Cisco IOS-based router, a Cisco ASA, and a Juniper SSG - they all employ the same technology.

Core

Before we can configure our tunnels, we need to know how they operate. You'll hear terms like phases, SAs, "interesting traffic", route based vs policy based, encryption, and a million other terms thrown around by NOC-monkies; this is where we'll explain everything you need to know to keep up in the conversation and impress your friends.

Let's begin by breaking down the order of operations for establishing an IPSec VPN.

First we'll need some traffic that wants to connect to a remote host. This is called "interesting traffic"; it's interesting because it triggers an ACL (or policy). This ACL/policy is being monitored by the VPN on your firewall. ACL is hit, traffic is tunneled - simple. This is a policy based VPN. The alternative would be a route based VPN; I find these very popular on ScreenOS. They require you to create a virtual tunnel interface to route traffic towards as you would any other interface.

Your VPN can be configured in one of two modes, Aggressive or Main. Aggressive is used when your remote LAN is using a dynamic IP address or behind NAT; this will cause the tunnel peer or hub (where your VPNs terminate) to consider VPN requests from any peer IP address. However, all interesting traffic will have to be initiated from the remote firewall; the head doesn't know the IP of its peer until the tunnel is established.

Once your remote firewall has interesting traffic that needs to be tunneled, it reaches out to its peer's IP and initiates what's referred to as "Phase One negotiations".  In Phase One, the two peers negotiate an authentication method, encryption algorithm, hash algorithm, and Diffie Hellman group as well as a timeout - this is known as the proposal in Junipers and a Transform Set in Cisco-world. After both sides are in an agreement an IKE SA is created and a secure connection has been created between them so they can safety start with Phase Two. If a single setting in the Phase One proposal is mismatched between peers, the IKE SA will fail to be established.

In Phase Two, the keying material is generated, and the two peers agree upon the policy that will be used (known as a proxy ID in Juniper-land when using a route based tunnel). This mode, which is called quick mode, differs from Phase One in that it can't occur until after Phase One is successful and all of the Phase Two packets are encrypted. This makes troubleshooting a little more difficult as it is possible for Phase One to be successful but Phase Two to fail. If Phase Two is successful, it will result in a Phase 2 SA, also called an IPSec SA, and the tunnel will be fully established.

I'll be going into more detail about everything mentioned above in Part 2, when we go through deploying both route based and policy based IPSec VPNs on a Juniper SSG Firewall from start to finish.