ASA Clientless SSL VPN traffic over IPsec LAN-to-LAN Tunnel Configuration Example

Document ID: 117739

Updated: Jul 03, 2014

Contributed by Cisco Engineers.



This document describes how to connect to a Cisco Adaptive Security Appliance (ASA) Clientless SSLVPN Portal and access a server that is located in a remote location connected over an IPsec LAN-to-LAN tunnel.



Cisco recommends that you have knowledge of these topics:

Components Used

The information in this document is based on the ASA 5500-X Series that runs Version 9.2(1), but it applies to all ASA versions.

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. Ensure that you understand the potential impact of any command before you make changes on a live network.

Background Information 

When traffic from a Clientless SSLVPN session traverses a LAN-to-LAN tunnel, note that there are two connections:

  • From the Client to the ASA
  • From the ASA to the destination host.

For the ASA-to-destination host connection, the IP address of ASA interface "closest" to the destination host is used. Therefore, the LAN-to-LAN interesting traffic must include a proxy-identity from that interface address to the remote network.

Note:  If Smart-Tunnel is used for a bookmark, the IP address of the ASA interface closest to the destination is still used. 


In this diagram, there is a LAN-to-LAN tunnel between two ASAs that allows traffic to pass from 192.168.10.x to 192.168.20.x.

The access-list that determines interesting traffic for that tunnel:


access-list l2l-list extended permit ip


access-list l2l-list extended permit ip


If the clientless SSLVPN user tries to communicate with a host on the 192.168.20.x network, ASA1 uses the address as the source for that traffic. Because the LAN-to-LAN Access Control List (ACL) does not contain as a proxy-identity, the traffic is not sent over the LAN-to-LAN tunnel.

In order to send traffic over the LAN-to-LAN tunnel, a new Access Control Entry (ACE) must be added to the interesting traffic ACL.


access-list l2l-list extended permit ip host


access-list l2l-list extended permit ip host

This same principle applies to configurations where the Clientless SSLVPN traffic needs to u-turn out the same interface it came in on, even if it is not supposed to go through a LAN-to-LAN tunnel.

Note: Use the Command Lookup Tool (registered customers only) in order to obtain more information on the commands used in this section.

Network Diagram

Typically, ASA2 conducts Port Address Translation (PAT) for the in order to provide Internet access. In that case, then traffic from on ASA 2 should be excluded from the PAT process when it goes to Otherwise, the response would not go through the LAN-to-LAN  tunnel. For example:   


nat (inside,outside) source static obj- obj- destination
static obj- obj-
object network obj-
nat (inside,outside) dynamic interface


Use this section in order to confirm that your configuration works properly.

The Output Interpreter Tool (registered customers only) supports certain show commands. Use the Output Interpreter Tool in order to view an analysis of show command output.

  • show crypto ipsec sa-Verify with this command that a Security Association (SA) between the ASA1 Proxy IP address and the remote network has been created. Check if the encrypted and decrypted counters increase when the Clientless SSLVPN user accesses that server.


This section provides information you can use in order to troubleshoot your configuration.

If the Security Association is not built, you can use IPsec debugging to the cause of failure:

  •  debug crypto ipsec <level>

Note: Refer to Important Information on Debug Commands before you use debug commands.

Updated: Jul 03, 2014
Document ID: 117739