LAN-to-LAN VPN on an ASA 5505

By stretch | Monday, July 11, 2011 at 1:37 a.m. UTC

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.

L2L_VPN.png

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

About the Author

Jeremy Stretch is a network engineer living in the Raleigh-Durham, North Carolina area. He is known for his blog and cheat sheets here at Packet Life. You can reach him by email or follow him on Twitter.

Posted in VPN

Comments


Deksta (guest)
July 11, 2011 at 4:05 a.m. UTC

Is there any special considerations for doing this with IPv6?


Guest cisco (guest)
July 11, 2011 at 6:53 a.m. UTC

Hello,

I have 2 questions for you :
1/ Do you know any possibility to monitor your VPN ? Like SNMP trapping or anything else to check remotly if it's alive ?
2/ Do you know a way to check since when the VPN goes on ?


emilio1973
July 11, 2011 at 8:28 a.m. UTC

just what I needed: thanks!!


MattG (guest)
July 11, 2011 at 10:10 a.m. UTC

It's probably worth mentioning that these type of connections are typically done through the ASDM as it reduces the risk of entering a typo.

Also, anyone who attempts this in a live environment should check that traffic directed at the peer isn't caught by a route that points the traffic at the internal interface of the ASA. I've seen this a few times and its easily missed.

Nice article, an example with NAT would be interesting as well.


Dinger (guest)
July 11, 2011 at 1:10 p.m. UTC

Note that in order to bring the VPN up, you must ping from a CLIENT from behind the ASA; by default, just pinging from the ASA itself won't do it (unless you specify the source interface, otherwise it routes externally)


RossC (guest)
July 11, 2011 at 2:56 p.m. UTC

I hate the way the ASDM creates site-to-site VPNs. I think its messy and confusing and much prefer to create them via a template in notepad or similar and use the cli.

Another thing to consider which also catches some people out is to make sure that if there are global NAT rules in place for certain ranges that need access to the internet, make sure you create a NAT exempt rule for the interesting traffic.


Gabriel (guest)
July 11, 2011 at 7:52 p.m. UTC

s/pre-shred/pre-shared


Doug Suida (guest)
July 11, 2011 at 8:39 p.m. UTC

Very nice. Just a few days ago I posted a video tutorial on how do do this using a GRE tunnel between two routers connected to the internet. Glad to see that the basic steps are the same using ASA or a router.


eoghancullen
July 11, 2011 at 10:02 p.m. UTC

Also note that the ASA's may be performing NAT between inside and outside. Because NAT will be performed before checking the crypto ACL, the traffic won't actually match the crypto ACL and won't be sent across the VPN. In this situation, you'll generally configure NAT exemption (i.e. don't NAT 'this traffic').

EDIT: From the documentation at the start of the article: http://www.cisco.com/en/US/docs/security/asa/asa82/configuration/guide/nat_bypassing.html#wp1080803


Smail (guest)
July 12, 2011 at 7:00 a.m. UTC

The command "packet-tracer" is good for testing, too.


IanJf (guest)
July 12, 2011 at 11:34 a.m. UTC

Just a small point!!
Isn't it recommended to Run DH Group 5 when using AES 256 bit encryption as group 2 and lower can sometimes run into problems with the sizes of AES 256...


eoghancullen
July 12, 2011 at 6:43 p.m. UTC

@IanJf

I had read as well alright. A quick google search hasn't returned any recommendations though and I'm too lazy right now to check my books. :)


abester1
July 12, 2011 at 7:34 p.m. UTC

Might worth nothing that PFS (Perfect Forward Secrecy) option can be enabled in the crypto map along with various idle and session timer lengths parameters which are configurable in both the crypto map section and the isakmp policy section.

Additionally, running debug, it would be very helpful to point out that Phase 1 of the tunnel refers to ISAKMP policy, while Phase 1.5 is the preshared key, and Phase 2 is IPSec configuration which is managed by the crypto map statement. Those are key information when debugging a failed vpn session and trying to figure out which phase you failed on and examine the configuration closer...

Jeremy, its a great post!!! Thanks


Kris (guest)
July 12, 2011 at 9:07 p.m. UTC

What are the main differences between LAN-to-LAN via:
1. ASA (as described)
2. GRE
3. L2TPv3

TCO of Hardware? Throughput? Security details?


nola
July 13, 2011 at 5:24 p.m. UTC

The use of VLAN1 = bad security practice.


jw21 (guest)
July 14, 2011 at 2:35 p.m. UTC

@Kris it is probably better to take l2tpv3 out of the comparison as it is a different service all together - layer 2 delivery over a l3 cloud.

@nola you are correct when it comes to switches, it is a completely different ideology on ASAs. The vlan should be well protected with access-lists for permissions.


andremta
July 19, 2011 at 6:18 a.m. UTC

That configuration is the same as for the 1841 and 2800?


j1 (guest)
July 31, 2011 at 1:17 a.m. UTC

@nola @jw21 vlan1 on access ports is only a bad idea if vlan1 is the native vlan on your trunks.


Marius
October 6, 2011 at 8:59 a.m. UTC

A Question. If there is LAN-to-LAN VPN using the pair of ASA 5505s between 2 sites. Can you have a subnetwork within one of the sites and connect to the subnetwork from a client?

I am typacillty thinking, Headoffice to branch VPN as described in the article. Then there is a project LAN that is (only) connected to the headoffice LAN via an ASA device. So, in the Headoffice you have to VPN from a client PC to the project network and at the branch you do the same, provided that the branch is connected via it's VPN to the head office.


A guest
October 6, 2011 at 1:42 p.m. UTC

I have one site with multi site connections through WAN. I have done similar configurations, but got two problem.
1. From one of the branches I can initiate, but from the main site I cann't.
2. The same configuration done on the 2nd site but I cann't initiate from that site. WAN link is ok.
Please sugest


A guest
October 6, 2011 at 2:11 p.m. UTC

A Question. I connect LAN-to-LAN VPN using the ASA 5510 at the main site ASA5505 at the other sites through WAN. I have done similar configuration on the main site and two other sites. Ican ping and intiate from the inside of one of the sites, but I canon't ping and intiate from the main site. on the other hand eventhough the same configuration is done, I can ping the outside network of the main site, but I cann't ping and initiate the inside network of the main site.
Please comment


iono (guest)
October 27, 2011 at 10:18 a.m. UTC

I'm running into some trouble with the ASA 5520. I have two identical units for the purpose of failover, the problem is that if I were to displace the cable for an uplink to the switch, it will not failover to the second ASA. However, if I were to power down the ASA completely it will switchover to the secondary ASA. Any help on this would greatly appreciated.


iaps (guest)
January 20, 2012 at 2:30 p.m. UTC

thanks for the post, nice update badly needed this...


av8rgeek (guest)
January 30, 2012 at 11:27 p.m. UTC

I like the article, but it doesn't really discuss a scenario where NAT translation is needed or wanted. For example:

Local Networks needing VPN access (on "inside" interface):
192.168.10.0/24, 192.168.20.0/24, 192.168.30.0/24
Public IP address (on "outside" interface): 1.1.1.1/24

Public IP address (some vendor firewall): 1.1.1.2/24
Vendor's network on "inside" interface: 10.10.10.0/25
Server A: 10.10.10.10
Server B: 10.10.10.20

In this scenario, I do not want my local workstations to connect to 10.10.10.10. I want them to connect to some translated IP, like 172.16.0.10. Also, I want the vendor to see my source IP as 172.16.x.x.

Example: Workstation A, 192.168.10.100 wants to Connect to Server A. However, they should not connect to 10.10.10.10, but 172.16.0.10 instead. When looking at the logs on Server A, the source IP of the connection should not be 192.168.0.10, but some translated IP.

I know this is easily possible, I'm just muddy on how to do it.


gogi100
July 12, 2012 at 8:23 p.m. UTC

i configured site to site VPN beetwen the asa 5505 (asa 8.4.2) and the asa 5510 (asa 8.4.4). how i can configure that the users from one side use internet and the site to site vpn in same time? the outside interface of asa5505 have address 10.15.100.8, the gateway for this network(10.15.100.0/24) is 10.15.100.1. this address of asa is nat-ed on public ip address.before LAN (10.15.100.0/24) has had many computers and used internet over the gateway 10.15.100.1 and now all computers must be move on behind asa5505. i configured the site to site vpn but internet doesn't work.
pls help me.
thanks

ps: this option is split tunneling? how it configure?


drazenmd (guest)
September 14, 2012 at 11:09 a.m. UTC

Hi,

I have a problem! I am configuring Site-to-Site VPN with another company. I already make a couple of tunnels but with this one I have a problem. They I already using on their side my local network 192.168.10.0/24 (server is 192.168.10.10) so we need to use imaginary network 172.16.0.5 as server address. Now I need to do NAT 172.16.0.5 to 192.168.10.10 but I am not so good in that.

Can anyone help me? I am using Cisco ASA 5510 (8.4)and ASDM 6.4


Ryan (guest)
January 25, 2013 at 7:07 a.m. UTC

Hey can this be done using dynamic ip addresses between the peers . Would be nice if you could put a dyndns alias as the peer address .


sydflyer (guest)
March 25, 2013 at 4:05 a.m. UTC

Good Article! But may anyone tell me functionality wise, what would be the difference between this and a normal site-to-site ipsec vpn?


TK (guest)
May 9, 2013 at 4:04 p.m. UTC

Does LAN A and LAN B have to be directly connected to the Inside interfaces on the routers/firewalls (F1/F2) for this configuration to work? I have the following topology that is not, and it's failing.

(LAN A)-(L3 SW)-(Subnet X)-(F1)-(L3 SW)-(F2)-(Subnet Y)-(L3 SW)-(LAN B)


GMAF (guest)
November 4, 2013 at 4:04 p.m. UTC

Will this configuration work is the two ASAs are directly connected with an ethernet cable. I have completed the above configuration and I am still unable to get any traffic to travel between my ASAs.


cedric (guest)
April 6, 2014 at 12:25 a.m. UTC

Perfect! Thanks for your time to give us that.

Leave a Comment


Optional; will not be displayed publicly or given out.
No commercial links. Only personal (e.g. blog, Twitter, or LinkedIn) and/or on-topic links, please.
Which interior routing protocol has a 15-hop limit?