Cisco SSL VPN Configuration

At the moment I play around with Cisco SSL VPN (WebVPN) and here some steps how to configured these on an Cisco ASA. SSL VPN is on one hand the Cisco Anyconnect client and on the other an Clientless SSL VPN over a portal what is running on the ASA.

I will not go into much detail here, it’s more basic configurations steps you need to configure to get it running.

For a basic set-up we need two network objects

object network inside-subnet  

object network sslvpn-subnet  

Then we define the DHCP pool for Anyconnect connections

ip local pool SSLVPNClientPool mask

We also need to make sure that Anyconnect clients communication with their original IP address and for that we need the following nat statement

nat (inside,outside) source static inside-subnet inside-subnet destination static sslvpn-subnet sslvpn-subnet

Here you select the Anyconnect package what you need to upload to your flash before and enable webvpn on your outside interface

  anyconnect image disk0:/anyconnect-win-2.4.1012-k9.pkg 1  
  enable outside  
  anyconnect enable  

In the SSL VPN client policy we define name server, domain name and DHCP pool. We also define here Anyconnect with ssl-client and the portal with ssl-clientless

group-policy SSLVPNClientPolicy internal 
group-policy SSLVPNClientPolicy attributes  
  dns-server value  
  default-domain value  
  address-pools value SSLVPNClientPool  
  vpn-tunnel-protocol ssl-client ssl-clientless  

We configure an SSL VPN tunnel group for remote access and set default policy to the SSL VPN client policy we configured in the step before

tunnel-group SSLVPNClientProfile type remote-access 
tunnel-group SSLVPNClientProfile general-attributes  
  default-group-policy SSLVPNClientPolicy  

Next, we define an external aaa server in my example an Windows Active Directory

aaa-server ldap-group protocol ldap
  aaa-server ldap-group (inside) host   
  ldap-base-dn OU=Departments, OU=DE, OU=Company, DC=domain,DC=com   
  ldap-login-dn cn=LDAPReader, OU=ServiceAccounts, OU=Company, DC=domain, DC=com   
  ldap-login-password secretpassword   
  ldap-naming-attribute sAMAccountName   
  ldap-scope subtree   
  server-type microsoft   

After we configured the external aaa server we need to link that in the tunnel group

tunnel-group SSLVPNClientProfile webvpn-attributes  
  group-alias SSLVPNClient enable  
  authentication-server-group ldap-group  

One of the last steps we enable the tunnel group within webvpn and configure sysopt permit-vpn

  tunnel-group-list enable  
sysopt connection permit-vpn

With the following command you can enable NTLM for a whole subnet if you use Windows IIS and integrate authentication

auto-signon allow ip auth-type ntlm

That’s it, quite easy and clear setup over the command line, you can also click yourself through the ASDM but it will definitively take longer.

Strange VPN behaviour between Juniper ISG and ASA

Always something new what is not working, this time a site-to-site VPN tunnel between a Juniper ISG 2000 and a Cisco ASA 5520. After the initial set-up what a colleague did everything seemed to work fine with the VPN, the tunnel come up and communication was possible. What my colleague not did was to do some intensive testing and check in detail the configuration.

The problems began ones these VPN tunnels were used for production traffic, they worked fine for some hours or maybe days but then suddenly you were not able to send or receive any data over the tunnel and mostly it happen over night where it was difficult to troubleshoot. In the beginning everybody said that it was a problem within the internet but when it happened three or four times a week I got suspicious that its something wrong with the boxes or even configuration.

First thing was to check the configuration and quickly I found a difference in the IPSec Phase2 default timers, the Juniper uses 1 hour and Cisco has 8 hours. I was happy and thought I found the reason for the connectivity problems but then two days later it happened again… 🙁

There where some strange syslog messages about anti-replay checking failed:

ASA-4-402119 IPSEC: Received an ESP packet (SPI= 0xFBEFD496, sequence number= 0x1C24) from (user= to that failed anti-replay checking.

These messages always came when we had the connectivity problems and that could be only now the last reason. I have to say I didn’t really found much but there were some articles that Juniper doesn’t support Cisco Anti-Replay checking and that you need to disable that on the Cisco side.

Here a release note I found from Juniper but it’s about Cisco’s GET VPN:

In the end that was the only thing I found and I thought give it a try and disable the anti-replay checking on the ASA when we had the problems again. I did so I waited until the problem happened again and disable the anti-replay checking with the following command:

crypto ipsec security-association replay disable

It’s global command were you disable the checking for the whole device. Here some more information:

When I disabled the checking the communication was suddenly possible again and since then the problem never happened again so the anti-replay checking was the cause of the connection problems between the Juniper and the Cisco. Always something new to learn 🙂

Bug in Cisco ASA 8.4(4)1 found

I had a new office set-up in Sao Paulo/Brazil and found a bug what should be already fixed but still exists. You cannot access the management interface (inside) of your ASA when you come over an L2L/RemoteAccess VPN and your NAT statements overlaps the management ip address.

It’s an split-tunneling configuration where VPN traffic keeps the original IP address and when you go into the internet you will translated to the outside IP address. Have a look here at the cisco bug CSCtr16184

I used the following config what didn’t work:

nat (inside,outside) source static inside-subs inside-subs destination static vpn-subs vpn-subs

When you use the NAT statements described in the workaround it works fine:

nat (inside,outside) source static inside-subs inside-subs destination static vpn-subs vpn-subs route-lookup
nat (outside,inside) source static vpn-subs vpn-subs destination static inside-subs inside-subs route-lookup

This behavior should be already fixed in version 8.4(2.3) but in my 8.4(4)1 it still exists.

Here the bug details from Cisco:

To-the-box traffic fails from hosts over vpn after upgrade to 8.4.2.


After upgrading the ASA to 8.4.2, all management traffic to-the-box(including icmp/telnet/ssh/ASDM) from hosts over the VPN (L2L or Remote ACcess VPN) may fail when destined to the management-access interface IP address.


1. Issue is observed if ASA is on 8.4.2. Not observed on 8.4.1.
2. Users directly connected to the internal interfaces face no issues with icmp/telnet/ssh/asdm to their respective interfaces.


The problem can be traced to a Manual NAT statement that overlaps with the management-access interface IP address. The NAT statement must have both the source and destination fields. Adding the “route-lookup” keyword at the end of the NAT statement resolves the issue.

ASA Config: Site-to-Site VPN with NAT

Christmas just went by and I had some time to write down an howto with NAT in an Site-to-Site VPN tunnel. In this scenario you have clients in site A who need to access servers in site B. Normally it is not possible to access the servers in site B when you’re using the same IP address space. You can only get this work if you’re using NAT in site A to hide the internal addresses. The only thing what you need to do is to find an address space for the NAT translation and you need to be sure that you’re not using the address space in site B where you want to access the server.

Its just an very easy example how to do that you can also do an configuration where you site A and B access each other so you need todo NAT on both sides and create an transfer network. If you have questions there just ask i will maybe also create an howto for that,

Site A

Internal IP address space:

Client IP addresses:

NAT IP address:

Site B

Internal IP address space:

Server IP addresses:

Configuration Site A:


object-group network Site-B-Access

object-group network VPN-Site-B

access-list nat_outbound-site-b extended permit ip object-group Site-B-Access object-group VPN-Site-B

nat (inside) 2 access-list nat_outbound-site-b

global (outside) 2 netmask

object-group network VPN-NAT-Site-B

access-list acl_inside extended permit icmp any object-group VPN-Site-B
access-list acl_inside extended deny ip any object-group VPN-Site-B

access-list acl_VPN-Site-B extended permit ip object-group VPN-NAT-Site-B object-group VPN-Site-B

tunnel-group type ipsec-l2l
tunnel-group ipsec-attributes
pre-shared-key secretpassword
isakmp keepalive threshold 10 retry 2

crypto map VPN 1 match address acl_VPN-Site-B
crypto map VPN 1 set peer
crypto map VPN 1 set pfs group2
crypto map VPN 1 set transform-set ESP-3DES-SHA
crypto map VPN 1 set connection-type bidirectional
crypto map VPN 1 set security-association lifetime seconds 3600 kilobytes 4608000
no crypto map VPN 1 set reverse-route
no crypto map VPN 1 set  nat-t-disable
crypto map VPN 1 set phase1-mode main
crypto map VPN 1 set inheritance rule
crypto map VPN 1 interface outside

Site B:


coming soon

so have a look in some days i will complete the post until then