23 November 2012

Cisco ASA: Anyconnect - How to source how many users and which users are logged in via Anyconnect?

With standard IPSEC/ISAKMP I am used to running "show crypto isa sa detail" style commands to figure out how many and who is logged into a client VPN session. With AnyConnect the above commands don't work. As AnyConnect is typically configured as a SSL VPN client, you have to use a different set of commands to troubleshoot. The below is for the Cisco ASA product set... there should be something similar for IOS devices.


FW01# show vpn-sessiondb anyconnect 
Session Type: AnyConnect
Username     : bob                Index        : 71
Assigned IP  : 10.0.1.1            Public IP    : x.x.x.x
Protocol     : AnyConnect-Parent SSL-Tunnel
License      : AnyConnect Essentials
Encryption   : RC4                    Hashing      : none SHA1
Bytes Tx     : 399272098              Bytes Rx     : 10860313
Group Policy : VPN_CLIENT_POLICY      Tunnel Group : VPN
Login Time   : 09:04:59 EST Fri Nov 23 2012
Duration     : 7h:02m:46s
Inactivity   : 0h:00m:00s
NAC Result   : Unknown
VLAN Mapping : N/A                    VLAN         : none
[...]
The above shows all active users logged into the SSL VPN client. You get their username, public IP and mapped VPN IP as well as the encryption mechanisms used. Pretty handy.

If you are just after an overview of how many users are connected the below is a good starting point. For the below I had 3 active VPN tunnels in use below.


FW01# show vpn-sessiondb          
---------------------------------------------------------------------------
VPN Session Summary                                                      
---------------------------------------------------------------------------
                               Active : Cumulative : Peak Concur : Inactive
                             ----------------------------------------------
AnyConnect Client            :      3 :         20 :           4 :        0
  SSL/TLS/DTLS               :      3 :         20 :           4 :        0
Clientless VPN               :      0 :          4 :           1
  Browser                    :      0 :          4 :           1
---------------------------------------------------------------------------
Total Active and Inactive    :      3             Total Cumulative :     24
Device Total VPN Capacity    :    250
Device Load                  :     1%
---------------------------------------------------------------------------
---------------------------------------------------------------------------
Tunnels Summary
---------------------------------------------------------------------------
                               Active : Cumulative : Peak Concurrent  
                             ----------------------------------------------
Clientless                   :      0 :          7 :               2
AnyConnect-Parent            :      3 :         17 :               4
SSL-Tunnel                   :      3 :         22 :               4
---------------------------------------------------------------------------
Totals                       :      6 :         46
---------------------------------------------------------------------------
 Hope this helps someone. Thanks for reading.

9 November 2012

Cisco ASA - How to allow client VPN access to site-to-site VPN reachable networks? (Hairpin routing)

Hello!

First thing is first, these were both fantastic resources/guides on how to get this working and I really can't stress this more "GO READ THEM FIRST":

The above links pretty much show the "how to get it setup". The below will consider a basic topology as follows:

"SITE-TO-SITE VPN REACHABLE OFFICE" --> "HEAD OFFICE ASA" <-- "REMOTE VPN CLIENT USER CONNECTING TO HEAD OFFICE"

The goal being to allow the VPN client user to reach the site-to-site VPN office via the head office ASA. The main steps to get  this working with ASA code 8.4 are:
  • Interesting-traffic ACLs - So, on the head office ASA, you basically need to allow the VPN client pool to be considered a source for traffic traversing the site-to-site VPN connection (i.e. adjusting the ACL for interesting traffic for the site-to-site VPN). For the remote site-to-site reachable office, the VPN router needs to have the VPN client pool marked as a VPN-interesting destination network across the VPN. Lastly, for client VPNs configuration on the head office ASA you need to make sure the client VPN configuration allows the client pool network access to the site-to-site VPN reachable networks as well.
  • NAT/NO-NAT statements - These are a bit mind-bending. Essentially, on the ASA side you need a "nat (outside,outside) [...]" statement which says "don't NAT traffic coming in on the outside interface from the VPN client pool going to site-to-site VPN reachable networks". You also need to pay attention to the "(inside,outside)" NO-NAT statements controlling how the internet-facing dynamic overload NAT takes effect. I'll cover this off in more detail the end as essentially this is the only thing that the above guides lacked...
  • Allowing intra-interface traffic traversal - ASAs by default don't allow "hairpin" routing... this means that if a packet is received on an interface (e.g. outside) and is destined to a network that according to the routing table is reachable via the same interface (e.g. outside) then drop the traffic. As client VPN and site-to-site VPN are both, from the ASA's perspective, reachable via the "same" interface of the ASA (outside) the packets are normally dropped. The command "same-security-traffic permit intra-interface" allows the ASA to process and allow same-interface routing of packets
Pretty much that is a summarized version of the linked documents. The issue I had twice over the last two days was that the NO-NAT for "(inside,outside)" traffic destination was taking effect and causing the ASA to sprout some error along the lines of:
"route lookup failed for host <VPN-CLIENT-IP> outside to <SITE-TO-SITE VPN REACHABLE IP> inside"
Essentially the no NAT rule I had in place doing overall inside to outside processing was as follows:
nat (inside,outside) source static any any destination static NO_NAT NO_NAT  
The NO_NAT object group simply defines all remote networks we don't want to NAT traffic on when traffic goes from inside to outside interfaces. The above config worked fine up until the point I needed the VPN client to hairpin route. Essentially on 8.4 code, any any NATs are evil. They take effect regardless of positioning in the rule-set and regardless of whether a NAT should logically match another rule above/etc.

The resolution is very easy though:
nat (inside,outside) source static SITE_LANS SITE_LANS destination static NO_NAT NO_NAT
This says that we don't NAT traffic to the NO_NAT destinations unless the source IP is from the site's LAN network ranges.

I found the best way to troubleshoot this was by:
  • Using ASDM logging and filtering by a specific traffic flow that "should" work (this is how I spotted the "route lookup failed" error) 
  • Using the "packet-tracer" utility to figure out which NAT statement it is being used by the ASA for a packet received on the outside interface going to a site-to-site VPN reachable IP.
Hope this helps someone!