How to: LAN-to-LAN VPN on an ASA 5505

Today we're going to look at LAN-to-LAN VPNs using the pair of ASA 5505s in the community lab. LAN-to-LAN VPNs are typically used to transparently connect geographically disparate LANs over an untrusted medium (e.g. the public Internet). Here we'll see how to configure a simple L2L VPN as pictured in the below topology in a few simple steps.

Initial Configurations

F1:

interface Vlan1
 nameif outside
 security-level 0
 ip address 172.16.1.2 255.255.255.252
!
interface Vlan2
 nameif inside
 security-level 100
 ip address 10.0.1.1 255.255.255.0
!
route outside 0.0.0.0 0.0.0.0 172.16.1.1 1

F2:

interface Vlan1
 nameif outside
 security-level 0
 ip address 172.16.2.2 255.255.255.252
!
interface Vlan2
 nameif inside
 security-level 100
 ip address 10.0.2.1 255.255.255.0
!
route outside 0.0.0.0 0.0.0.0 172.16.2.1

 Step 1: ISAKMP Policy

First we need to define an ISAKMP policy. ISAKMP is used to establish the initial asymmetrically encrypted channels between the two endpoints so that they can securely negotiate a pair of one-way IPsec security associations (SAs). For more background on IPsec fundamentals, see my IPsec quick and dirty article.

For simplicity, we'll use a static pre-shared key for ISAKMP authentication (which will be defined in step four).

F1(config)# isakmp policy 1
F1(config-isakmp-policy)# authentication pre-share
F1(config-isakmp-policy)# encryption aes-256
F1(config-isakmp-policy)# hash sha
F1(config-isakmp-policy)# group 2
F1(config-isakmp-policy)# lifetime 86400
F1(config-isakmp-policy)# exit
F1(config)# isakmp enable outside

The finished configuration can be copied verbatim from F1 to F2:

crypto isakmp enable outside
crypto isakmp policy 1
 authentication pre-share
 encryption aes-256
 hash sha
 group 2
 lifetime 86400

Step 2: IPsec Transform Set

An IPsec transform set establishes the encryption and authentication (HMAC) methods to be employed by the IPsec SAs. While it is possible to enable several options, both sides of our VPN will be configured to support only 256-bit AES and SHA-1. Our transform set is named L2L.

F1(config)# crypto ipsec transform-set L2L esp-aes-256 esp-sha-hmac

F2(config)# crypto ipsec transform-set L2L esp-aes-256 esp-sha-hmac

Step 3: Create an ACL to Match Traffic

Next we need to create an access list to match plain (unencrypted) traffic which should be encrypted and routed through the IPsec tunnel between the two LANs. This access list will be referenced by the crypto map we'll create in step five. In the real world, crypto map ACLs can be quite complex. For our purposes, however, we only need to match traffic going between the 10.0.1.0/24 and 10.0.2.0/24 networks.

F1(config)# access-list LAN_Traffic extended permit ip 10.0.1.0 255.255.255.0 10.0.2.0 255.255.255.0

We flip the addresses on F2 to match traffic heading the opposite direction:

F2(config)# access-list LAN_Traffic extended permit ip 10.0.2.0 255.255.255.0 10.0.1.0 255.255.255.0

 Step 4: Create a Tunnel Group

A tunnel group holds tunnel configuration parameters, namely the connection type and authentication method. Since we're using pre-shred key authentication, we need to name our tunnel group as the IP address of the remote peer. Also, notice that we must define the connection type (ipsec-l2l) before we can configure the pre-shared key.

F1(config)# tunnel-group 172.16.2.2 ?

configure mode commands/options:
  type  Enter the type of this group-policy
F1(config)# tunnel-group 172.16.2.2 type ipsec-l2l
F1(config)# tunnel-group 172.16.2.2 ?

configure mode commands/options:
  general-attributes  Enter the general-attributes sub command mode
  ipsec-attributes    Enter the ipsec-attributes sub command mode
F1(config)# tunnel-group 172.16.2.2 ipsec-attributes
F1(config-tunnel-ipsec)# pre-shared-key ThisIsAWeakKey

The tunnel group configuration on F2 is identical except that its name changes to 172.16.1.2 (F1's outside interface):

tunnel-group 172.16.1.2 type ipsec-l2l
tunnel-group 172.16.1.2 ipsec-attributes
 pre-shared-key ThisIsAWeakKey

Step 5: Create and Apply a Crypto Map

Finally, we need to create a crypto map (named L2L) to tie together the IPsec transform set, access list, and tunnel group configured in the previous steps. First we match LAN-to-LAN traffic using our access list:

F1(config)# crypto map L2L 1 match address LAN_Traffic

Then we set the VPN peer and IPsec transform set to use:

F1(config)# crypto map L2L 1 set peer 172.16.2.2
F1(config)# crypto map L2L 1 set transform-set L2L

The corresponding crypto map on F2 looks like this:

crypto map L2L 1 match address LAN_Traffic
crypto map L2L 1 set peer 172.16.1.2
crypto map L2L 1 set transform-set L2L

All that's left now is to apply the crypto map to the outside interface on each firewall:

F1(config)# crypto map L2L interface outside

F2(config)# crypto map L2L interface outside

Testing

Our LAN-to-LAN VPN won't actually establish until one of the firewalls detects traffic matching our crypto map's access list (10.0.1.0/24 to 10.0.2.0/24 or vice versa). To initiate the VPN, we can ping from one LAN host to another:

F1_Client# ping 10.0.2.9

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

Notice that the far-end LAN client appears to be directly connected to the local client:

F1_Client# traceroute 10.0.2.9

Type escape sequence to abort.
Tracing the route to 10.0.2.9

1 10.0.2.9 8 msec *  0 msec

We can see information about the ISAKMP and IPsec SAs between F1 and F2 with the commands show isakmp sa and show ipsec sa:

F1# show isakmp sa

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: 172.16.2.2
    Type    : L2L             Role    : initiator
    Rekey   : no              State   : MM_ACTIVE

F1# show ipsec sa
interface: outside
    Crypto map tag: L2L, seq num: 1, local addr: 172.16.1.2

      access-list LAN_Traffic permit ip 10.0.1.0 255.255.255.0 10.0.2.0 255.255.255.0
      local ident (addr/mask/prot/port): (10.0.1.0/255.255.255.0/0/0)
      remote ident (addr/mask/prot/port): (10.0.2.0/255.255.255.0/0/0)
      current_peer: 172.16.2.2

      #pkts encaps: 4, #pkts encrypt: 4, #pkts digest: 4
      #pkts decaps: 4, #pkts decrypt: 4, #pkts verify: 4
      #pkts compressed: 0, #pkts decompressed: 0
      #pkts not compressed: 4, #pkts comp failed: 0, #pkts decomp failed: 0
      #pre-frag successes: 0, #pre-frag failures: 0, #fragments created: 0
      #PMTUs sent: 0, #PMTUs rcvd: 0, #decapsulated frgs needing reassembly: 0
      #send errors: 0, #recv errors: 0

      local crypto endpt.: 172.16.1.2, remote crypto endpt.: 172.16.2.2

      path mtu 1500, ipsec overhead 74, media mtu 1500
      current outbound spi: 62323606
...

If your ISAKMP SA never progresses past the MM_WAIT_MSG state, you most likely have a connectivity issue between the two VPN endpoints. See more troubleshooting tips here.

The VPN traffic generated by the ping above looks like this. The first ICMP request across the VPN triggers the building of the VPN and is discarded. The remaining four ICMP requests and responses are encrypted in the eight ESP packets at the end of the capture.

 SOURCE: http://packetlife.net/blog/2011/jul/11/lan-lan-vpn-asa-5505/