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.
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
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 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
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.