0% found this document useful (0 votes)
319 views4 pages

IPsec Quick and Dirty

The document describes setting up an IPsec VPN tunnel between routers R1 and R3. It involves: 1) Configuring an IKE policy on each router to authenticate using pre-shared keys. 2) Defining an IPsec transform set to encrypt traffic using 3DES and authenticate using SHA-1. 3) Applying the transform set to an IPsec profile attached to the tunnel interfaces, converting the tunnels from GRE to IPsec mode. This establishes IPsec security associations between the routers to encrypt and authenticate traffic flowing through the tunnel.

Uploaded by

sgopal7
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
319 views4 pages

IPsec Quick and Dirty

The document describes setting up an IPsec VPN tunnel between routers R1 and R3. It involves: 1) Configuring an IKE policy on each router to authenticate using pre-shared keys. 2) Defining an IPsec transform set to encrypt traffic using 3DES and authenticate using SHA-1. 3) Applying the transform set to an IPsec profile attached to the tunnel interfaces, converting the tunnels from GRE to IPsec mode. This establishes IPsec security associations between the routers to encrypt and authenticate traffic flowing through the tunnel.

Uploaded by

sgopal7
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 4

IPsec quick and dirty

By stretch | Monday, July 14, 2008 at 1:08 a.m. UTC

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:

R1# show int tun0 | include protocol


Tunnel0 is up, line protocol is up
Tunnel protocol/transport GRE/IP

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:

R1(config)# crypto isakmp policy 10


R1(config-isakmp)# authentication pre-share
R1(config-isakmp)# ^Z
R1# sh crypto isakmp policy

Global IKE policy


Protection suite of priority 10
encryption algorithm: DES - Data Encryption Standard (56 bit keys).
hash algorithm: Secure Hash Standard
authentication method: Pre-Shared Key
Diffie-Hellman group: #1 (768 bit)
lifetime: 86400 seconds, no volume limit
...

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:

R1(config)# crypto ipsec transform-set MyTransformSet esp-3des esp-sha-hmac


R1(cfg-crypto-trans)# ^Z
R1# show crypto ipsec transform-set
Transform set MyTransformSet: { esp-3des esp-sha-hmac }
will negotiate = { Tunnel, },

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:

R1(config)# crypto ipsec profile MyProfile


R1(ipsec-profile)# set transform-set MyTransformSet
R1(ipsec-profile)# ^Z
R1# show crypto ipsec profile
IPSEC profile MyProfile
Security association lifetime: 4608000 kilobytes/3600 seconds
PFS (Y/N): N
Transform sets={
MyTransformSet,
}

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:

R1(config)# interface tun0


R1(config-if)# tunnel mode ipsec ipv4
R1(config-if)# tunnel protection ipsec profile MyProfile

If all goes well, we should now have an ISAKMP security association and two unidirectional IPsec security associations between
the tunnel endpoints:

R1# show crypto isakmp sa


IPv4 Crypto ISAKMP SA

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

R1# show crypto ipsec sa

interface: Tunnel0
Crypto map tag: Tunnel0-head-0, local addr 172.16.0.1

protected vrf: (none)


local ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)
remote ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)
current_peer 172.16.0.6 port 500
PERMIT, flags={origin_is_acl,}
#pkts encaps: 5, #pkts encrypt: 5, #pkts digest: 5
#pkts decaps: 5, #pkts decrypt: 5, #pkts verify: 5
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 0, #pkts compr. failed: 0
#pkts not decompressed: 0, #pkts decompress failed: 0
#send errors 0, #recv errors 0

local crypto endpt.: 172.16.0.1, remote crypto endpt.: 172.16.0.6


path mtu 1500, ip mtu 1500, ip mtu idb FastEthernet0/0
current outbound spi: 0xB1677585(2976347525)

inbound esp sas:


spi: 0x5351D51E(1397871902)
transform: esp-3des esp-sha-hmac ,
in use settings ={Tunnel, }
conn id: 3, flow_id: SW:3, crypto map: Tunnel0-head-0
sa timing: remaining key lifetime (k/sec): (4540862/3379)
IV size: 8 bytes
replay detection support: Y
Status: ACTIVE

inbound ah sas:

inbound pcp sas:

outbound esp sas:


spi: 0xB1677585(2976347525)
transform: esp-3des esp-sha-hmac ,
in use settings ={Tunnel, }
conn id: 4, flow_id: SW:4, crypto map: Tunnel0-head-0
sa timing: remaining key lifetime (k/sec): (4540862/3378)
IV size: 8 bytes
replay detection support: Y
Status: ACTIVE

outbound ah sas:

outbound pcp 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

crypto isakmp policy 10


authentication pre-share
crypto isakmp key FooB4r address 172.16.0.6
!
crypto ipsec transform-set MyTransformSet esp-3des esp-sha-hmac
!
crypto ipsec profile MyProfile
set transform-set MyTransformSet
!
interface Tunnel0
ip address 10.0.0.1 255.255.255.252
tunnel source 172.16.0.1
tunnel destination 172.16.0.6
tunnel mode ipsec ipv4
tunnel protection ipsec profile MyProfile
!
interface FastEthernet0/0
ip address 172.16.0.1 255.255.255.252

R3

crypto isakmp policy 10


authentication pre-share
crypto isakmp key FooB4r address 172.16.0.1
!
crypto ipsec transform-set MyTransformSet esp-3des esp-sha-hmac
!
crypto ipsec profile MyProfile
set transform-set MyTransformSet
!
interface Tunnel0
ip address 10.0.0.2 255.255.255.252
tunnel source 172.16.0.6
tunnel destination 172.16.0.1
tunnel mode ipsec ipv4
tunnel protection ipsec profile MyProfile
!
interface FastEthernet0/0
ip address 172.16.0.6 255.255.255.252

Posted in Security

http://packetlife.net/blog/2008/jul/14/ipsec-quick-and-dirty/ Page 4

You might also like