ASA Lan-to-Lan IKEV1 VPN

Today we will configure a Lan to Lan VPN using GNS3 and a pair of ASA 5520. Lets start with a diagram of the topology.

First, we will configure the interfaces and ip addresses on both firewalls.

LB-ASA:

 interface GigabitEthernet1

  nameif inside

  security-level 100

  ip address 10.162.7.240 255.255.255.0


 interface GigabitEthernet0

  nameif outside

  security-level 0

  ip address 10.162.9.247 255.255.255.0

BM-ASA:

 interface GigabitEthernet1

   nameif inside

   security-level 100

   ip address 10.162.8.240 255.255.255.0

 interface GigabitEthernet0

   nameif outside

   security-level 0

   ip address 10.162.9.246 255.255.255.0

Now lets teach the asa how to route packets with a default route:

LB-ASA:

 route outside 0.0.0.0 0.0.0.0 10.162.9.246

BM-ASA

 route outside 0.0.0.0 0.0.0.0 10.162.9.247

Is a good practice to test site to site connectivity between the two vpn peers.

 bm-asa# ping 10.162.9.247
 Type escape sequence to abort.
 Sending 5, 100-byte ICMP Echos to 10.162.9.247, timeout is 2 seconds:
 !!!!!
 Success rate is 100 percent (5/5), round-trip min/avg/max = 1/56/80 ms

In the example we are configuring now, there is no nat in place, so we don´t want to worry about nat for now.

Next we can create a couple of network object that we can use later in our configuration.

LB-ASA:

 object network LOCAL-VLAN-7

  subnet 10.162.7.0 255.255.255.0

 object network REMOTE-VLAN-8

  subnet 10.162.8.0 255.255.255.0

BM-ASA:

 object network LOCAL-VLAN-8

  subnet 10.162.8.0 255.255.255.0

 object network REMOTE-VLAN-7

  subnet 10.162.7.0 255.255.255.0

Now, we need to define the ISAKMP policy that will be used in the stablishment of the IKE Phase 1 Tunnel. In our case, we are using, pre-shared key authentication, AES 128 encryption, sha HMAC, and Diffie-Hellman group 2.

LB-ASA:

 crypto ikev1 policy 1

  authentication pre-share

  encryption aes

  hash sha

  group 2

  lifetime 86400

BM-ASA:

 crypto ikev1 policy 1

  authentication pre-share

  encryption aes

  hash sha

  group 2

  lifetime 86400

We need to define the security parameters used in the IPSec Tunnel (IKE Phase 2). In our case, we are using AES 128 for the encryption and sha HMAC.

LB-ASA:

 crypto ipsec ikev1 transform-set IKEV1TSET esp-aes esp-sha-hmac

BM-ASA:

crypto ipsec ikev1 transform-set IKEV1TSET esp-aes esp-sha-hmac

In the next steep, we need to identify the trafic to protect, so we need to create an ACL to match the traffic we want to encrypt. Here, we will make use of the object groups previously defined.

LB-ASA:

access-list CRYPTO-ACL extended permit ip object LOCAL-VLAN-7 object REMOTE-VLAN-8

BM-ASA:

access-list CRYPTO-ACL extended permit ip object LOCAL-VLAN-8 object REMOTE-VLAN-7

We need to create a group policy where we can define aditional parameters of the connection.

LB-ASA:

 group-policy L2L-GROUP-POLICY internal

 group-policy L2L-GROUP-POLICY attributes

  vpn-tunnel-protocol ikev1

BM-ASA:

group-policy L2L-GROUP-POLICY internal

group-policy L2L-GROUP-POLICY attributes

 vpn-tunnel-protocol ikev1

Lets continue configuring the tunnel-group (aka connection profile). The tunnel group contains several configuration parameters of the connection. We need to name the tunnel with the ip address of the remote peer. Also in the configuration of the tunnel group is where we assign the group policy that we created one step before.

LB-ASA:

tunnel-group 10.162.9.246 type ipsec-l2l

tunnel-group 10.162.9.246 general-attributes

 default-group-policy L2L-GROUP-POLICY

tunnel-group 10.162.9.246 ipsec-attributes

 ikev1 pre-shared-key Pr3Sh4r3d

BM-ASA:

tunnel-group 10.162.9.247 type ipsec-l2l

tunnel-group 10.162.9.247 general-attributes

 default-group-policy L2L-GROUP-POLICY

tunnel-group 10.162.9.247 ipsec-attributes

 ikev1 pre-shared-key Pr3Sh4r3d

We are almost finish. Now we need to create a crypto map, that will tie together the crypto acl, the isakmp policy, the connection profile and the transform set and we have to attach it, to the outside interface.

LB-ASA:

crypto map L2L-CRYPTO-MAP 1 match address CRYPTO-ACL

crypto map L2L-CRYPTO-MAP 1 set peer 10.162.9.246

crypto map L2L-CRYPTO-MAP 1 set ikev1 transform-set IKEV1TSET

crypto map L2L-CRYPTO-MAP interface outside

BM-ASA:

crypto map L2L-CRYPTO-MAP 1 match address CRYPTO-ACL

crypto map L2L-CRYPTO-MAP 1 set peer 10.162.9.247

crypto map L2L-CRYPTO-MAP 1 set ikev1 transform-set IKEV1TSET

crypto map L2L-CRYPTO-MAP interface outside

And finally we enable ikev1 protocol on the outside interface.

LB-ASA:

crypto ikev1 enable outside

BM-ASA:

crypto ikev1 enable outside

Now we can test our connection with a simple ping from one of our clients to a client in the remote site.

C:\Documents and Settings\Administrator>ping 10.162.8.2

Pinging 10.162.8.2 with 32 bytes of data:

Request timed out.
Reply from 10.162.8.2: bytes=32 time=50ms TTL=128
Reply from 10.162.8.2: bytes=32 time=69ms TTL=128
Reply from 10.162.8.2: bytes=32 time=87ms TTL=128


Ping statistics for 10.162.8.2:

    Packets: Sent = 4, Received = 3, Lost = 1 (25% loss),

Approximate round trip times in milli-seconds:

    Minimum = 50ms, Maximum = 87ms, Average = 68ms

We loose the first ping because the ipsec tunnel is not active but the rest are successful.
We can see the status of the tunnel in our ASAs, with the commands:

show crypto ikev1 sa , show crypto ipsec sa and show crypto ipsec sa summary
LB-ASA:

lb-asa# show crypto ikev1 sa

IKEv1 SAs:

   Active SA: 1
   Rekey SA: 0 (A tunnel will report 1 Active and 1 Rekey SA during rekey)

Total IKE SA: 1

1   IKE Peer: 10.162.9.246

    Type    : L2L             Role    : initiator

    Rekey   : no              State   : MM_ACTIVE

BM-ASA:

bm-asa# show crypto ikev1 sa

IKEv1 SAs:

   Active SA: 1
   Rekey SA: 0 (A tunnel will report 1 Active and 1 Rekey SA during rekey)

Total IKE SA: 1

1   IKE Peer: 10.162.9.247

    Type    : L2L             Role    : responder

    Rekey   : no              State   : MM_ACTIVE

I started the comunication flow from the LB-ASA and we can see in the output, that is the initiator, while the BM-ASA is the responder.

Lets complicate the example a little bit more, introducing a PAT translation so the internal clients will be able to access the internet.

LB-ASA:

object network INSIDE-HOSTS

 subnet 10.162.7.0 255.255.255.0

object network INSIDE-HOSTS

 nat (inside,outside) dynamic interface

BM-ASA:

object network INSIDE-HOSTS

 subnet 10.162.7.0 255.255.255.0

object network INSIDE-HOSTS

 nat (inside,outside) dynamic interface

Lets try to stablish the tunnel again.

C:\Documents and Settings\Administrator>ping 10.162.8.2

Pinging 10.162.8.2 with 32 bytes of data:

Request timed out.
Request timed out.
Request timed out.
Request timed out.

Ping statistics for 10.162.8.2:
    Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

The tunnel is not comming up, why?
The NAT process of the ASA is executed before the crypto acl, so the crypto acl cannot identify the traffic to send through the tunnel. To fix the issue we need to configure the NAT exemption (identity NAT). We will not translate the traffic flow destined to the VPN tunnel.

LB-ASA:

nat (inside,outside) source static LOCAL-VLAN-7 LOCAL-VLAN-7 destination static REMOTE-VLAN-8 REMOTE-VLAN-8

BM-ASA:

nat (inside,outside) source static LOCAL-VLAN-8 LOCAL-VLAN-8 destination static REMOTE-VLAN-7 REMOTE-VLAN-7

Now, if we try to stablish the tunnel again

C:\Documents and Settings\Administrator>ping 10.162.8.2

Pinging 10.162.8.2 with 32 bytes of data:

Request timed out.
Reply from 10.162.8.2: bytes=32 time=64ms TTL=128
Reply from 10.162.8.2: bytes=32 time=50ms TTL=128
Reply from 10.162.8.2: bytes=32 time=39ms TTL=128

Ping statistics for 10.162.8.2:
    Packets: Sent = 4, Received = 3, Lost = 1 (25% loss),
Approximate round trip times in milli-seconds:
    Minimum = 39ms, Maximum = 64ms, Average = 51ms