Das Blinken Lichten

You could add this to my ‘Commands I always forget’ post, but since I’m going to turn this into a little bit of a walk through I decided to make it into it’s own post.  Most admins use two commands to verify IPSec VPN security associations.  Those, of course, are…

ASA# show crypto isakmp sa

and

ASA# show crypto ipsec sa

Both of these commands provide you with a wealth of information about the IPSec connection.  However, what about if you start talking about SSL VPN sessions?  Or WebVPN sessions?  Since these technically aren’t IPSec connections, they don’t show up in the ‘show crpypto’ commands.  Below I’ll walk through a couple of commands which show you some more information about all types of VPN connections.

How to see current WebVPN Sessions
ASA# show vpn-sessiondb webvpn
Session Type: WebVPN
Username     : langemakj              Index        : 13
Public IP    : 10.20.30.78
Protocol     : Clientless
License      : SSL VPN
Encryption   : RC4                    Hashing      : SHA1
Bytes Tx     : 147092                 Bytes Rx     : 31993
Group Policy : GP_SSLVPN              Tunnel Group : TG_SSLVPN
Login Time   : 14:04:01 CST Thu Jul 29 2010
Duration     : 0h:00m:11s
NAC Result   : Unknown
VLAN Mapping : N/A                    VLAN         : none
Notes: So as you can see, this gives you a ton of info on the connection including the users group policy, tunnel group, and their public IP (Note: I’m testing off of the internal ASA interface hence the RFC 1918 addressing).

How to log off current WebVPN Sessions
ASA# vpn-sessiondb logoff name langemakj
Do you want to logoff the VPN session(s)? [confirm]
INFO: Number of sessions with name "langemakj" logged off : 1
Notes: What’s interesting about the log off procedure is that its done by tunnel group or username.  Note in this instance, I don’t even have to note that it’s a WebVPN session that I want to log off.  Conversely, if I wanted to log off all of the WebVPN sessions I could just input ‘vpn-sessiondb logoff webvpn’ which would log off all users connected to WebVPN.

Wrap up
So now that we have an idea of how it works with WebVPN connections, let’s use the trusty ‘?’ to see what else we can do with the ‘vpn-sessiondb’.

ASA# show vpn-sessiondb ?
  detail       Show detailed output
  email-proxy  Email-Proxy sessions
  full         Output formatted for data management programs
  index        Index of session
  l2l          IPsec LAN-to-LAN sessions
  ratio        Show VPN Session protocol or encryption ratios
  remote       IPsec Remote Access sessions
  summary      Show VPN Session summary
  svc          SSL VPN Client sessions
  vpn-lb       VPN Load Balancing Mgmt sessions
  webvpn       WebVPN sessions
  |            Output modifiers
  <cr>

As you can see, you can use the vpn-sessiondb command to look at each type of VPN connection.  While I usually still use the ‘show crypto’ commands for IPSec connections, you HAVE to use the vpn-sessiondb for AnyConnect and WebVPN.  Play around with it, remember, the ‘?’ is your best friend!

I had the opportunity to configure ISP failover on an ASA the other day and I thought I’d share the configuration as well as a couple of tips on using it.  I recall that when I started working on ASA’s I would always read that ‘dual ISP’ support was a feature of the Security Plus (Sec+) licensing set.  To me, that always meant that it was its own feature and had its own configuration commands.  As it turns out, that’s not the case.  In fact, the only reason you really need Sec+ to accomplish this is so that you have can have an additional ‘full’ interface.  The rest of the configuration is really just a SLA monitor, tracked default routes, and a extra global NAT pool.  Let’s walk through the configuration on a 5505.  I’m going to only touch the major parts of this so please don’t consider this a full build.

Notes
-Insert your relevant information between <>
-Console prompts are show in green
-Text in blue are variable names I made up, feel free to change them

Configure your interfaces
Inside Interface
ASA(config)# interface Vlan1
ASA(config-if)#description Inside Interface
ASA(config-if)# nameif inside
ASA(config-if)# ip address <Inside IP> <Inside Mask>

Outside Interface
ASA(config)# interface Vlan2
ASA(config-if)# description Primary ISP
ASA(config-if)# nameif outside
ASA(config-if)# ip address <ISP 1 IP> <ISP 1 Mask>

Backup ISP Interface
ASA(config)# interface Vlan3
ASA(config-if)# description Backup ISP
ASA(config-if)# nameif backupisp
ASA(config-if)# security-level 0
ASA(config-if)# ip address <ISP 2 IP> <ISP 2 Mask>

Assign them to switchports
ASA(config)# interface Ethernet0/0
ASA(config-if)# switchport access vlan 2
ASA(config)# interface Ethernet0/1
ASA(config-if)# switchport access vlan 3
Notes: VLAN 1 is the default so I’m not assigning it, just use one of the other ports for it.

Configure NAT
Define your Global pools
ASA(config)# global (outside) 1 <An IP in your Primary ISPs pool that you want to use for NAT/PAT>
ASA(config)# global (backupisp) 1 <An IP in your Backup ISPs pool that you want to use for NAT/PAT>
Notes: You need to define both the primary and backup address as global pools to match up against the NAT pool.  I totally forgot about that during the install and couldn’t figure out why I wasn’t passing traffic.

Define your inside NAT
ASA(config)# nat (inside) 1 0.0.0.0 0.0.0.0
Notes: Some people use a specific network here, I always just use 0 0 if its a small setup

Configure the SLA Monitor
ASA(config)# sla monitor 10
ASA(config-sla-monitor)# type echo protocol ipIcmpEcho 4.2.2.2 interface outside
ASA(config-sla-monitor-echo)# num-packets 3
ASA(config-sla-monitor-echo)# timeout 1000
ASA(config-sla-monitor-echo)# frequency 3
ASA(config)# sla monitor schedule 10 life forever start-time now
Notes: Ok, so here is the actual ‘failover’ piece of all of this. So I’ll break it down piece by piece. 
Line 1 – Configures a SLA monitor with the ID of 10
Line 2 – Configures the monitoring protocol and the target of the monitoring probe.  In this case I chose 4.2.2.2 since I have been able to ping that magical IP address since the beginning of time.  You also need to tell it which interface to source the ICMP traffic from.  In this case, it would be the outside interface. 
Line 3 – Sets the number of packets to be sent in each probe.
Line 4 – Configures the timeout period in milliseconds. 
Line 5 – Configures the frequency of the probe in seconds. 
Line 6 – Instructs the ASA to start SLA monitor 10 now and let it run for forever. 

Configure the Route tracking
ASA(config)#route outside 0.0.0.0 0.0.0.0 <ISP 1 Default route> 1 track 1
ASA(config)#route backupisp 0.0.0.0 0.0.0.0 <ISP 2 Default route> 254
Notes: Here we define the default network routes out to the internet.  Notice that we define out normal default route with an administrative distance of 1.  However, we also add the ‘track 1’ statement at the end.  This means that this route being in the routing table is dependant on tracked item 1 (If you don’t know what that means hold on, we’ll get there soon enough).  We also install a second route for the backup ISP which HAS to have a higher administrative distance than the primary ISP’s default route. 

ASA(config)# track 1 rtr 10 reachability
Notes: This is where the magic happens.  The above statement reads like this in plain English.  “Keep an eye on SLA monitor 10 and when it fails any routes associated with me also fail”.  So what happens is when the SLA monitor fails, the tracked route gets removed from the routing table, and the route with the higher administrative distance comes in and takes its place since its the best available route. 

Summary
So it’s a pretty cool setup if you are ONLY looking for outbound internet failover.  Keep in mind that all of your static NATs, external DNS entries, VPNs, etc won’t work when your primary ISP fails (assuming that’s the IP they are all assigned on).  This particular client had me make a primary and a backup PCF file for their Cisco VPN clients so that they could access the VPN when they were in a failover state.  Then I just added the backup ISP interface to the crypto map for their client VPN and turned on ISAKMP on the backup ISP interface.  Keep in mind though that the backup VPN will only work when the backup ISP circuit is live and the primary VPN will only work when the primary ISP circuit is live.  Both will never work at the same time.

I’ve been trying to spend some time lately playing with my ASA again.  I’ve recently found myself playing with NAT and DMZ functionality.  I have to admit that for what appears to be  simple concept there is a lot material to digest.  I’m also trying to look into the new ASA code release and get up to speed on the new NAT config commands.  Unfortunately my ASA doesn’t have a Security Plus license so I don’t have full DMZ functionality.

So if someone from Cisco is reading this and wants to send me a Security Plus activation code so I can blog about it that would be cool : )

NAT configuration is always something that draws a lot of attention.  NAT can perform lots of different functions in many different configurations.  That being said, it can be complex to understand at first.  However, I think its probably more important to understand NAT than any other function on the ASA’s.  If you don’t fully understand the concept you can get yourself in a lot of trouble real fast.  So lets get right into it and look at a couple of scenarios and examples.  In this post I’m going to talk about the most common NAT configurations.  In upcoming posts we’ll talk about NAT DMZ configurations and policy NAT.

The standard 5505 overload
I call this the ‘standard’ because its pretty typical to see on a 5505 box.  The client usually has 1 external IP and has a couple of services with a single subnet behind it.  Nothing too special here.

ASA(config)# global (outside) 1 interface
ASA(config)# nat (inside) 1 0.0.0.0 0.0.0.0

So, what does this mean?  Lets break it down. 
The Global Command
global – Indicates that we are defining a global address pool.  This can either be a pool of addresses or a single IP that’s being overloaded through the use of PAT
(outside) – The item in the parenthesis is the interface we are defining the pool on.  In this case, its the outside interface
1 – Specifies the ID of the pool, this will be matched up against the internal NAT pool
interface – The interface keyword specifies that PAT is being used with the IP defined on the interface.  PAT (also referred to as overload) uses a single external IP address for all of the clients in the NAT pool.  To make the distinction clear, NAT usually means that you are using a pool of IP’s and PAT usually means you are using one external IP. 

The Nat command
nat – The NAT command is what you use to associate a network with a pool of global addresses
(inside) – The item in the parenthesis is the interface in which the NAT network exists.  In this case its going to be on the inside interface
1 – This number is what is used to pair the global and NAT statements together.  In other words, global pool 1 will be used with NAT network 1. 
0.0.0.0 0.0.0.0 – Translates to mean all networks.  If there is only a single internal subnet that requires translation this could just as easily read something like ‘192.168.127.0 255.255.255.0’. 

Summary
This configuration PATs all of the internal traffic heading out to the public network to the single IP address defined on the external interface.

Defining an actual NAT pool
Lets take the same scenario as above but define a real pool of IP’s for inside clients to NAT to. 

ASA(config)# global (outside) 1 <Begin Range>-<End Range>
ASA(config)# nat (inside) 1 0.0.0.0 0.0.0.0

This configuration is exactly the same as above save the fact that we defined a range of IPs for NAT to use.  In this scenario, users that were heading out to the public network would use one of the actual IPs defined within the range rather than all using the same IP in an overloaded configuration. 

Putting them together.
We’ve reviewed two options for basic NAT at this point.  One using NAT overload and one defining a NAT pool.  These are the classic NAT/PAT examples and they both work equally well in different scenarios.  However option 2 has a gotcha attached to it.  Lets say that you have 30 users and 20 IPs defined in your NAT pool.  What happens when the 21st users attempts to make a NAT request?  Nothing.  Since you are out of IP addresses there isn’t one for that user to use.  The best practice is to define a single NAT overload in addition to the range of IPs.  That way, if the NAT pool fills up, subsequent users can start using PAT.  An example is shown below.

ASA(config)# global (outside) 1 <Begin Range>-<End Range – 1>
ASA(config)# global (outside) 1 <End Range>
ASA(config)# nat (inside) 1 0.0.0.0 0.0.0.0

The ASA will evaluate any range definitions prior to moving to PAT on the single IP.  So here we took the last IP in the range and defined it for PAT in the case that our NAT range becomes oversubscribed.  Seeing as the ASA cant PAT approximately 64,000 sessions through a single external IP, one PAT statement is usually enough.  If you wish two PAT ranges can be defined and will be used in order.

Summary
In this post we took a look at what I would call basic NAT/PAT’.  The idea of this post was to get you familiar with build blocks of NAT and see a couple of common implementations.   In the next couple of posts we’ll talk about policy NAT and NAT configuration with a DMZ interface.