IPsec Quick and Dirty
IPsec Quick and Dirty
A reader of last week's post Visualizing tunnels asked for an IPsec example, so here's a rundown continuing from the previous
setup. Note that the VTI configuration demonstrated here is different from the older crypto map method used as an example in the
IPsec cheat sheet.
The tunnel between R1 and R3 is currently running GRE, the default encapsulation:
A ping from one end of the tunnel's 10.0.0.0/30 subnet to the other verifies end-to-end connectivity.
IKE Configuration
Our first task in converting to an IPsec tunnel is specifying an Internet Key Exchange (IKE) policy. IKE relies on ISAKMP to
establish an initial secure channel over which the IPsec tunnel can be negotiated. An IKE policy determines the attributes of the
ISAKMP session, including the encryption type and hashing methods.
An empty IKE/ISAKMP policy provides default selections for all attributes. The only attribute we need to manually define in this
case is the authentication method, which we'll change from the default of RSA signatures to pre-shared keys (more on this in a bit).
We can inspect the completed policy with show crypto isakmp policy:
Our default policy implements DES encryption with SHA-1 hashing and Diffie-Hellman group 1. Don't worry if these terms are
foreign to you. There's quite a bit more detail to this whole process, but for now just remember that encryption is used to scramble
and unscramble data, whereas hashing uses a small fixed-length checksum (or HMAC) to provide data integrity. The default tunnel
lifetime is 86400 seconds (24 hours).
As mentioned, we'll need to define a pre-shared key (versus implementing stronger but more complex public keying). The key is a
string of text used to initialize the IKE tunnel, configured identically on both routers. In our example, the string FooB4r is used; in
practice, I would obviously suggest a much stronger key. The IP address which follows the key definition specifies the host for
which the key should be used.
http://packetlife.net/blog/2008/jul/14/ipsec-quick-and-dirty/ Page 1
R1(config)# crypto isakmp key 0 FooB4r address 172.16.0.6
Make sure to reflect this configuration on the opposite end of the tunnel at R3 (use 172.16.0.1 instead of .6). For a full account of
IKE policy and authentication configuration, check the official documentation.
IPsec Configuration
Once our IKE policy has been setup we can move on to defining an IPsec transform set. The transform set defines the parameters
of the IPsec security associations which will carry the actual data. Note that although we have defined a single tunnel (interface
Tunnel0), there will be two unidirectional IPsec security associations, one in either direction.
Unlike defining an IKE policy, which provides a default for all attributes, we must explicitly state the encryption and hash type we
want to use with our transform set. Our example will implement ESP encapsulation with 3DES encryption and SHA-1
authentication. Within transform set configuration, we have the option to select tunnel or transport mode; tunnel mode is the
default, and suits our scenario. We can inspect our newly created transform set with show crypto ipsec transform-set:
For more information on configuring IPsec transform sets, consult the IOS documentation.
Now that we have our IPsec transform set created, we can reference it from an IPsec profile to be applied to a tunnel interface:
This step admittedly seems superfluous; why can't we simply reference the transform set directly? In more real-world scenarios,
the IPsec profile can serve as a wrapper which points to multiple transform sets, and grants the ability to set additional options
beyond the scope of this article.
Tunnel Configuration
Our last step is to convert the tunnel interfaces on routers 1 and 3 to IPsec operation. First we change the tunnel mode from GRE
to IPsec for IPv4, then apply our IPsec profile:
If all goes well, we should now have an ISAKMP security association and two unidirectional IPsec security associations between
the tunnel endpoints:
http://packetlife.net/blog/2008/jul/14/ipsec-quick-and-dirty/ Page 2
dst src state conn-id slot status
172.16.0.6 172.16.0.1 QM_IDLE 1002 0 ACTIVE
interface: Tunnel0
Crypto map tag: Tunnel0-head-0, local addr 172.16.0.1
inbound ah sas:
outbound ah sas:
More information on configuring IPsec across Virtual Tunnel Interfaces (VTIs) is available in the IOS documentation.
http://packetlife.net/blog/2008/jul/14/ipsec-quick-and-dirty/ Page 3
Traffic flowing through the tunnel is now encapsulated, encrypted, and authenticated with IPsec. For an example of what the
encrypted traffic looks like on the wire, check out this packet capture.
Final Configurations
R1
R3
Posted in Security
http://packetlife.net/blog/2008/jul/14/ipsec-quick-and-dirty/ Page 4