Upgrading a Cisco IPS

This tutorial will guide you through upgrading the firmware on an IPS (Intrusion Prevention System) sensor. We don't want our systems hacked by Chloe from 24, so we need to keep our stuff in tip-top shape! Onward!

Set it up

Download the image file(s) from support.cisco.com You can up/download them to an FTP, SCP, HTTP, or HTTPS server; provided your sensor can access it.

Pull it down

Log into the sensor via a terminal console (telnet or ssh). In configuration mode, we need to pull the image file we downloaded off our server. This example uses our FTP server:

conf t

upgrade ftp://ftpuser@192.168.1.1/IPS-K9-X.X-X-XX.pkg

You'll be prompted for a password, so put it in

Enter password: ********

Enter yes to complete the upgrade.

The device will pull the image off the server, decompress, install, then reboot. Once rebooted log back in via terminal and check the version.

show ver

And that's it! Chloe can go whine to Jack because she can't get in anymore.

Armageddon (Optional!)

IPS modules are usually in-line, meaning they're the cream filling in our Oreo network. If they go down, everything goes down. So you've unleashed the fires of hell upon earth!

Alright, there's a couple things you can do to prevent this from going four-horsemen bad.

1. Make sure to have someone on site, next to the rack, rearing to go

2. Have a cabling contingency; so you can bypass the failed IPS

3. Have another IPS to swap in!

Even with all that, you'll need to get it back to a clean-working state. For this we'll need ROMMON (woo!)

Gather

ROMMON is the boot-loader of an Cisco device, much like on an Android phone. It allows you to manage system files without booting into the OS. Download the IPS system image file to the tftp root directory of a TFTP server that is accessible from your IPS. Make sure you can access the TFTP server location from the network connected to the Ethernet port of your IPS.

Press Break or Esc at the following prompt while the system is booting to interrupt boot. Press the spacebar to begin boot immediately.

You have ten seconds to press Break or Esc.

Use BREAK or ESC to interrupt boot.
Use SPACE to begin boot immediately.

The system enters ROMMON mode. The rommon> prompt appears.

Check the current network settings.

rommon> set

ROMMON Variable Settings:
ADDRESS=0.0.0.0
SERVER=0.0.0.0
GATEWAY=0.0.0.0
PORT=Management0/0
VLAN=untagged
IMAGE=
CONFIG=

The variables have the following definitions:
Address: Local IP address of IPS
Server: TFTP server IP address where the application image is stored
Gateway: Gateway IP address used by IPS
Port: Ethernet interface used for IPS management
VLAN: VLAN ID number (leave as untagged)
Image: System image file/path name Config—Unused by these platforms

Not all values are required to establish network connectivity. The address, server, gateway, and image values are required.

The default interface used for TFTP downloads is Management0/0, which corresponds to the MGMT interface of IPS.

Verify that you have access to the TFTP server by pinging it from your local Ethernet port with one of the following commands.

rommon> ping 192.168.1.1

Define the path and filename on the TFTP file server from which you are downloading the image.

rommon> IMAGE=path/file_name

Caution Make sure that you enter the IMAGE command in all uppercase. You can enter the other ROMMON commands in either lower case or upper case, but the IMAGE command specifically must be all uppercase.

UNIX Example

rommon> IMAGE=/system_images/IPS 4240-K9-sys-1.1-a-7.0-4-E4.img

The path is relative to the default tftpboot directory of the UNIX TFTP server. Images located in the default tftpboot directory do not have any directory names or slashes in the IMAGE specification.

Windows Example

rommon> IMAGE=\system_images\IPS 4240-K9-sys-1.1-a-7.0-4-E4.img

Enter set and press Enter to verify the network settings.

You can use the sync command to store these settings in NVRAM so they are maintained across boots. Otherwise, you must enter this information each time you want to boot an image from ROMMON.

Deploy

Download and install the system image.

rommon> tftp

To avoid corrupting the system image, do not remove power from the IPS while the system image is being installed.

If the network settings are correct, the system downloads and boots the specified image on the IPS. Be sure to use the correct IPS image. And now we're back to square-one, BUT without the fire and brimstone. :)

GRE pass-through on ZBF

Simple little config snippet for a Cisco Zone-Based firewall.

First you need to put in a deny statement for GRE traffic in an ACL.
Deny? Wait a second, don't we want traffic to pass?
Well of course we do! But if you remember in a Zone-Based firewall your outbound ACL is used in a class-map to inspect traffic; dynamically allowing bi-directional sessions. The reason we want to deny it is you can't inspect GRE traffic; it just doesn't work.

(config)#ip access-list extended ACL_PERMIT_GRE
(config-ext-nacl)#deny gre any any

Okay so we're not inspecting traffic, but we still need to pass it. To do this we have make a class-map to nest under out outbound and inbound policy-maps.

Now we'll create our class-map which matches GRE traffic, referencing the ACL we just made:

(config)#class-map type inspect match-all CMAP_PASS_GRE
(config-cmap)#match access-group name ACL_PERMIT_GRE

Then we want to apply this to our policy maps and define the action as pass.
The policy maps I'm applying these to also contain class-maps for generic traffic.

(config)#policy-map type inspect PMAP_UNTRUST_TO_TRUST
(config-pmap)#class type inspect CMAP_PASS_GRE
(config-pmap-c)#pass

(config)#policy-map type inspect PMAP_TRUST_TO_UNTRUST
(config-pmap)#class type inspect CMAP_PASS_GRE
(config-pmap-c)#pass

And that's about it, your GRE should be good to go. This will work for PPTP pass-through on a Cisco IOS running in ZBF and the same principal should apply for an ASA.

Site-to-Site VPNs - Part 1: The Basics

I've been getting a lot of questions lately about VPNs (virtual private networks); how they work, what are they, how to configure them. To most CCNA graduates it can be a bit confusing. Seeing as more than half the work in our NOC consists of VPN-related issues I thought it'd be good to get everything out in the open for those who aren't sure about them.

There are a couple different types of VPN connections (L2L, RAS, SSL, etc), however we're going to just with the basics and cover a site-to-site connection.

If you have your CCNA, you should be familiar with the concept of Frame-Relay. It allows two private networks to connect to one another as if there was nothing but a router in between. Nowadays we generally use MPLS or VPNs in place of a Frame-Relay PVC. What this allows you to do is more easily and dynamically connect multiple subnetworks together for very cheap (and in VPN cases, basically free - provided you have the equipment).

Speaking of equipment, we'll be covering three in these posts: a Cisco IOS-based router, a Cisco ASA, and a Juniper SSG - they all employ the same technology.

Core

Before we can configure our tunnels, we need to know how they operate. You'll hear terms like phases, SAs, "interesting traffic", route based vs policy based, encryption, and a million other terms thrown around by NOC-monkies; this is where we'll explain everything you need to know to keep up in the conversation and impress your friends.

Let's begin by breaking down the order of operations for establishing an IPSec VPN.

First we'll need some traffic that wants to connect to a remote host. This is called "interesting traffic"; it's interesting because it triggers an ACL (or policy). This ACL/policy is being monitored by the VPN on your firewall. ACL is hit, traffic is tunneled - simple. This is a policy based VPN. The alternative would be a route based VPN; I find these very popular on ScreenOS. They require you to create a virtual tunnel interface to route traffic towards as you would any other interface.

Your VPN can be configured in one of two modes, Aggressive or Main. Aggressive is used when your remote LAN is using a dynamic IP address or behind NAT; this will cause the tunnel peer or hub (where your VPNs terminate) to consider VPN requests from any peer IP address. However, all interesting traffic will have to be initiated from the remote firewall; the head doesn't know the IP of its peer until the tunnel is established.

Once your remote firewall has interesting traffic that needs to be tunneled, it reaches out to its peer's IP and initiates what's referred to as "Phase One negotiations".  In Phase One, the two peers negotiate an authentication method, encryption algorithm, hash algorithm, and Diffie Hellman group as well as a timeout - this is known as the proposal in Junipers and a Transform Set in Cisco-world. After both sides are in an agreement an IKE SA is created and a secure connection has been created between them so they can safety start with Phase Two. If a single setting in the Phase One proposal is mismatched between peers, the IKE SA will fail to be established.

In Phase Two, the keying material is generated, and the two peers agree upon the policy that will be used (known as a proxy ID in Juniper-land when using a route based tunnel). This mode, which is called quick mode, differs from Phase One in that it can't occur until after Phase One is successful and all of the Phase Two packets are encrypted. This makes troubleshooting a little more difficult as it is possible for Phase One to be successful but Phase Two to fail. If Phase Two is successful, it will result in a Phase 2 SA, also called an IPSec SA, and the tunnel will be fully established.

I'll be going into more detail about everything mentioned above in Part 2, when we go through deploying both route based and policy based IPSec VPNs on a Juniper SSG Firewall from start to finish.

Subnetting 101

I had a hard time picking all this up from reading books on it, but after understanding it it's a lot simpler than you would think.

First you'll want to remember to use binary conversion chart; anyone familiar with computers should feel at home with these; they're the same values used for unit sizes on file systems.

 128  64  32  16  8  4  2  1

Each one of these represent a bit in the octet of the subnet mask; added together, the "turned on" bits will give you the value of that octet (binary can only hold a value of 1 or 0, true or false, on or off).

10110101 will be 128+32+16+4+1 so the octet would be 181

Nitty Gritty

There are two ways to subnet, by desired host, and by desired networks. Doing by networks will usually result in an excess of host addresses. However doing it by hosts, if done incorrectly, can result in too few addresses and limit the scalability of your networks.

Address space we'll be working with:

Network address: 172.16.0.0
Subnet Mask: 255.255.0.0
CIDR: /16

By Network

Number of desired networks will be twenty (20).

Begin by using the chart above to see how many network bits you would need to get at least 20.
You'll want to add the number of bits onto the left most octet available.

128 64 32 16 8 4 2 1
     0  0   0   1 0 1 0 0
                   ^---------^
                     5 bits

255.255.0.0        =    11111111.11111111.00000000.00000000
255.255.248.0    =    11111111.11111111.11111000.00000000
                                                                   ^------^
                                                              5 bits added                                   

The subnet mask decimal value is calculated by adding up the binary values according to our little chart. Where as your CIDR notation is the number of actual bits added up (one full octet is equal to eight (8)).

128 64 32 16 8 4 2 1
     1  1   1   1 1 0 0 0
 
128+64+32+16+8 = 248
Subnet Mask: 255.255.248.0

11111111.11111111.11111000.00000000
CIDR: /21

The way I usually calculate usable range is to subtract the subnet mask from 256. However technically the formula is 2^n where n is equal to the number of available host bits in the left most octet.

256-248 = 8
2^3 = 2x2x2 = 8

So our network range becomes 172.16.0.0-172.16.0.7 (remember that the first IP is the network address, and the last is the broadcast; so host IPs are 172.16.0.1 through 172.16.0.6).

Finding the total number of available networks is similar.

2^n where n = number of network bits added
so 2^5 =  32 networks available

By Host

Calculating by host requirement is almost the same thing, except backwards...ish

Number of desired hosts will be twenty (20)

Start off with the same thing as before, find the number of bits requires for the number you're looking for, this time hosts instead of networks.

128 64 32 16 8 4 2 1
    0   0   0   1 0 1 0 0
                   ^---------^
                      5 bits

Now for the backwards part. The five bits will be how many host bits will remain (so you would need the inverted amount of network bits)

255.255.0.0            =    11111111.11111111.00000000.00000000
255.255.255.224    =    11111111.11111111.11111111.11100000
                                                                                             ^-------^
                                                                                   5 bits remaining

Everything aside from that one step is the same.
Usable range is 172.16.0.0-172.16.0.32 with a CIDR of /27 (you can subtract host bits from 32 if that's any easier for you) and usable number of networks being 2^11 which is 2048.

And that's about it. I find this logic a lot easier to understand than the things I've seen elsewhere.

Upgrading IOS-XE (3850 switch stack)

Copy image file over as you normally would for any Cisco device.

copy ftp://user:password@192.168.2.1/cat3k_caa-universalk9.SPA.03.03.02.SE.150-1.EZ2.bin flash:

Before we can do the upgrade, we need to make sure that the switches are operating in install mode. To do this use the show ver command.

3850Stack#show ver | begin Switch Ports
Switch Ports Model              SW Version        SW Image              Mode  
------ ----- -----              ----------        ----------            ----  
*    1 56    WS-C3850-48T       03.03.00SE        cat3k_caa-universalk9 INSTALL
     2 56    WS-C3850-48T       03.03.00SE        cat3k_caa-universalk9 INSTALL

Install Mode
This is the default mode for the switch. The INSTALL mode uses a package-provisioning file named packages.conf in order to boot the switch. In addition, there are a number of .pkg files in the flash. Cisco recommends that you do not alter these files unless directed by a Cisco Technical Assistance Center (TAC) engineer.

Bundle Mode
If you are comfortable with the use of traditional monolithic IOS images in order to boot the switch, then the BUNDLE mode should be familiar. The BUNDLE mode consumes more memory than the INSTALL mode because the packages are extracted from the Bundle and copied to the RAM.

Use the show switch command to view the cluster's current status

3850Stack#show switch
Switch/Stack Mac Address : 30cc.d16f.1f91 - Local Mac Address
Mac persistency wait time: Indefinite
                                             H/W   Current
Switch#   Role    Mac Address     Priority Version  State
------------------------------------------------------------
*1       Active   30cc.d16f.1f91    1      A0      Ready              
 2       Standby  3512.d834.cd91     1      A0      Ready              

With the switch in install mode, you can install any supported Cisco IOS-XE software bundle by using the software install command. The new operand denotes that only packages within the bundle being installed will be used (think of it as a clean install).

3850Stack#software install file flash:cat3k_caa-universalk9.SPA.03.03.02.SE.150-1.EZ2.bin new                  
Preparing install operation ...
[1]: Copying software from active switch 1 to switch 2
[1]: Finished copying software to switch 2
[1 2]: Starting install operation
[1 2]: Expanding bundle flash:cat3k_caa-universalk9.SPA.03.03.02.SE.150-1.EZ2.bin
[1 2]: Copying package files
[1 2]: Package files copied
[1 2]: Finished expanding bundle flash:cat3k_caa-universalk9.SPA.03.03.02.SE.150-1.EZ2.bin
[1 2]: Verifying and copying expanded package files to flash:
[1 2]: Verified and copied expanded package files to flash:
[1 2]: Starting compatibility checks
[1 2]: Finished compatibility checks
[1 2]: Starting application pre-installation processing
[1 2]: Finished application pre-installation processing
[1]: Old files list:
    Removed cat3k_caa-base.SPA.03.03.00SE.pkg
    Removed cat3k_caa-drivers.SPA.03.03.00SE.pkg
    Removed cat3k_caa-infra.SPA.03.03.00SE.pkg
    Removed cat3k_caa-iosd-universalk9.SPA.150-1.EZ.pkg
    Removed cat3k_caa-platform.SPA.03.03.00SE.pkg
    Removed cat3k_caa-wcm.SPA.10.1.100.0.pkg
[2]: Old files list:
    Removed cat3k_caa-base.SPA.03.03.00SE.pkg
    Removed cat3k_caa-drivers.SPA.03.03.00SE.pkg
    Removed cat3k_caa-infra.SPA.03.03.00SE.pkg
    Removed cat3k_caa-iosd-universalk9.SPA.150-1.EZ.pkg
    Removed cat3k_caa-platform.SPA.03.03.00SE.pkg
    Removed cat3k_caa-wcm.SPA.10.1.100.0.pkg
[1]: New files list:
    Added cat3k_caa-base.SPA.03.03.02SE.pkg
    Added cat3k_caa-drivers.SPA.03.03.02SE.pkg
    Added cat3k_caa-infra.SPA.03.03.02SE.pkg
    Added cat3k_caa-iosd-universalk9.SPA.150-1.EZ2.pkg
    Added cat3k_caa-platform.SPA.03.03.02SE.pkg
    Added cat3k_caa-wcm.SPA.10.1.121.0.pkg
[2]: New files list:
    Added cat3k_caa-base.SPA.03.03.02SE.pkg
    Added cat3k_caa-drivers.SPA.03.03.02SE.pkg
    Added cat3k_caa-infra.SPA.03.03.02SE.pkg
    Added cat3k_caa-iosd-universalk9.SPA.150-1.EZ2.pkg
    Added cat3k_caa-platform.SPA.03.03.02SE.pkg
    Added cat3k_caa-wcm.SPA.10.1.121.0.pkg
[1 2]: Creating pending provisioning file
[1 2]: Finished installing software.  New software will load on reboot.
[1 2]: Committing provisioning file

[1 2]: Do you want to proceed with reload? [yes/no]: yes
[1 2]: Reloading

Once the reboot is complete (which can take several minutes depending on the size of stack) verify update.

3850Stack#show ver | begin Switch Ports 
Switch Ports Model              SW Version        SW Image              Mode  
------ ----- -----              ----------        ----------            ----  
*    1 56    WS-C3850-48T       03.03.02SE        cat3k_caa-universalk9 INSTALL
     2 56    WS-C3850-48T       03.03.02SE        cat3k_caa-universalk9 INSTALL

Installing and configuring Rancid

If you have more than a couple devices in your network, you might find backing up conifig files to be a tedious task. If you have more than a handful (which most network admins will); it can become a quest..

This is where Rancid comes in, it's a small application for Linux which lets you automate the process You can also make it execute commands on the same remote devices automatically (good for clearing tunnels or other resets). It's also good because it supports Fortinet FortiGates (which for their all-in-one nature and cheapness are on the rise). But the most difficult thing I found was trying to get it installed and configured properly.

First you'll want to install your favourite flavour of linux; I'll be using Ubuntu simply due to it's popularity and available repositories.

Open up a terminal window and get to installin'

sudo apt-get install rancid

This will install Rancid onto your machine into /var/lib/rancid. It will also create a new user called rancid to be used with the application. I couldn't find any documentation on what the default password is for this user (however at least one person suggested it was rancid, that didn't work for me) so we'll want to go ahead and change it.

sudo passwd rancid

You'll be prompted to input a new password and confirm it, for simplicity's sake I just stuck with rancid.

Now we can start to configure Rancid itself. It nests devices in groups, you can execute commands to a group as a whole which makes management a lot easier. To add a group you'll have to edit the rancid.conf file, you can find this in /etc/rancid/

You'll see a bunch of commented lines in there already; we need to add one to the bottom. If you're not familiar with VI, use the arrow keys to get down to the line you want to input on, press i to enter INSERT mode and begin typing. Once you're finished, hit ESC and type :wq to write to the file and quit VI and return to the terminal.

vi /etc/rancid/rancid.conf    LIST_OF_GROUPS="toronto montreal vancouver"   :wq

Each group name is seperated by blank space, you can put in as many as you like; we'll be adding our devices to these groups afterwards.

Now that we have our groups in order, we need to generate the CVS files for them. We'll want to run this command as our rancid user.

sudo su -c /var/lib/rancid/bin/rancid-cvs -s /bin/bash -l rancid

This will generate a directory for each of the groups you defined earlier in /var/lib/rancid/
Each directory will contain a router.db file, this is where we'll be storing our device information
So back into VI we go!

sudo vi /var/lib/rancid/toronto/router.db

The router.db files have a specific syntax and if you mess it up, it won't work; so be careful!
For a basic entry you'll need to input the following

#toronto-c1811
192.168.2.1:cisco:up

This will point at a Cisco device with the IP of 192.168.2.1 and tell Rancid that the device is up. Each variable is separated by a colon. If the status is set to down the script will ignore that device. Rancid supports the use of FQDNs in place of IP addresses, however I do not use them. Lines beginning with # are comments, it would be good habit to comment each device you add (even if you're using an FQDN). For the entire list of options refer to the man page from Shrubbery Networks

So Rancid knows where to find our devices, but like hell it'll be able to login; so we need to define that as well. Rancid keeps all it's login information in .cloginrc located in /var/lib/rancid/. When I installed Rancid, this file wasn't auto-generated (apparently there's a sample-cloginrc but I wasn't able to find it on my machine) so I had to create it with VI:

sudo vi /var/lib/rancid/.cloginrc

Quick linux note: anything starting with a period is a "hidden" file and will not show up with ls

We should have a blank VI file open right now, get into INSERT mode and put in your box's login creds.

add method 192.168.2.1 ssh
add user 192.168.2.1 cisco
add password 192.168.2.1 cisco cisco

The first line will define what protocol to connect with, in the case you have SSH and Telnet enabled (which I would advise against but whatever)
You can put in:

add method 192.168.2.1 ssh telnet

Rancid will first attempt to connect on SSH, then fall back to Telnet in the event of a failure. The second line is the username, and the third is both the password and the enable password. Now there is a lot of other options you can put here which I don't personally use, but feel free to browse them on the man page.

I found that for Rancid to run we'll have to give our rancid user ownership of rancid install directory and turn our new login file into read/writeble (but not exedcuteable) only by it's owner (which we're about to make rancid)

sudo chmod 600 /var/lib/rancid/.cloginrcsudo 

chown -R rancid:rancid /var/lib/rancid

Now we're ready to run Rancid!

sudo su -c /var/lib/rancid/bin/rancid-run -s /bin/bash -l rancid

It should take a little bit to run (depending on how many devices you have an how big their config files are)
Once it's finished you can check the log in /var/log/rancid and check your config file in /var/lib/rancid/toronto/configs/192.168.2.1

And thats it! Put it on a cron job and you'll never have to do it manually again.

Observium Integration

This was a very annoying task to get to work, but once it's work its bloody brilliant.
You'll have to do things a little differently because Observium uses hostnames opposed to IP addresses for adding devices. So I went and edited my /etc/hosts file to reflect the devices I was adding.

Open your config file for Observium and point towards your Rancid configs:

vi /opt/observium/config.php 

$config['rancid_configs'][]              = '/var/lib/rancid/toronto/configs/';
$config['rancid_ignorecomments']        = 0;

Now provided your config files are showing up with hostnames opposed to IP addresses. Everything should  work. However this is where I got stuck, and it's the most linux of problems; user groups. Observium will be accessing the Rancid config  using the apache's www-data user, which isn't in our rancid user group.

usermod -a -G rancid www-data

Now once you restart your apache service (service apache2 restart) you should be good to go! You'll know its working because Observium will add a config tab to the device page.

NOTE: I had installed Rancid on top of Turnkey's Observium distro and found that telnet was not installed by default; apt-get install telnet to fix.

 

EasyVPN LDAP Authentication

The following is a tutorial on how to enable an ASA to use LDAP (Active Directory) group policy for log-in authentication when connecting via Cisco EasyVPN.

LDAP stands for Lightweight Directory Access Protocol, which is an application protocol for accessing and maintaining distributed directory information services over an Internet Protocol (IP) network. Or in simpler terms, LDAP lets you access AD.

For the sake of this tutorial we will be adding a group to an ASA 5510

Add the AD group to the attribute map

We need to tell the ASA what domain and group to look at for the authentication process.

An attribute map for our purposes, is essentially a list of VPN groups that we want to use.
CN=Foobar VPN is setting Foobar VPN as the AD group. This is the exact name configured on the AD Server.
OU=VPN Groups is setting the OU as "VPN Groups". This is the OU that contains the Foobar VPN group on the AD Server.
DC=foobar, DC=com sets the domain as foobar.com
and lastly FoobarVPN is the local (the ASA's) name for this group.

ldap attribute-map LDAPAttMap
 map-value memberOf "CN=Foobar VPN,OU=VPN Groups,DC=foobar,DC=com" FoobarVPN

Define a group policy

So the ASA knows about the Windows server, but we don't have a local group policy set up for the VPN group. There's a whole whack of attributes that can be defined so lets get crackin'.

We won't be using a WINS server so here we define that as none. But we do have two local DNS servers, 192.168.1.11 and .12. The group policies allow you to define how many users that we're going to allow in at once. For this group we only want three at any one time.The vpn-filter is just an ACL to be applied to this tunnel. vpn-tunnel-protocol allows us to choose which encryption protocol we wish to use for the tunnel, here we've chosen SSL. This VPN is a split-tunnel , which allows users to access a public network (the internet) as well as a LAN at the same time using the same physical connection. Which LANs are accessible can be defined using the split-tunnel-network-list command. The value is simply another ACL. default-domain simply defines the domain this VPN will be accessing. address-pools lets us choose the DHCP pool we'll be using for addressing the connected clients. And lastly, we tell the ASA that the clients will be connecting through WebVPN and that the Cisco AnyConnect installer should remain installed after use.

group-policy FoobarVPN internal
group-policy FoobarVPN attributes
 wins-server none
 dns-server value 192.168.1.11 192.168.1.12
 vpn-simultaneous-logins 3
 vpn-filter value FoobarFilter
 vpn-tunnel-protocol ssl-client
 split-tunnel-policy tunnelspecified
 split-tunnel-network-list value FoobarVPN_Split
 default-domain value foobar.com
 address-pools value VPNPool
 webvpn
 anyconnect keep-installer installed

Setup a tunnel-group for remote access

Now that we have the ASA aware of the AD server and the group we need to use. We have to setup a tunnel group for our users. Tunnel groups contain a small number of attributes that pertain to creating the tunnel itself. Tunnel groups include a pointer to a group policy that defines user-oriented attributes.

Firstly, we have to set the FoobarVPN group that we defined previously as a remote-access group.
Now we can start to define some general attributes.

address-pool VPNPool defines VPNPool as the DHCP address pool (this pool is not defined in this tutorial). You can set up to 10 external DHCP servers and 6 pools. Because we are using the ASA as the DHCP server, it is not explicitly defined here.

authentication-server-group Foobar_LDAP specifies Foobar_LDAP as the AAA server group. This tutorial assumes this as been pre-defined. I'll include a snippet on how to quickly configure it at the bottom of this page.

default-group-policy FoobarVPN tells the ASA that the FoobarVPN we created in step two is the default policy group for this tunnel-group.

Going into the webvpn-attributes sub-tree we can enable WebVPN to use the FoobarVPN we defined in step two.

tunnel-group FoobarVPN type remote-access
tunnel-group FoobarVPN general_attributes
 address-pool VPNPool
 authentication-server-group Foobar_LDAP
 authentication-server-group (Internal) Foobar_LDAP
 default-group-policy FoobarVPN
tunnel-group FoobarVPN webvpn-attributes
 group-alias FoobarVPN enable

Bonus Round! Setting up the Authentication Server!

Welcome to the bonus round! This snippet will help you in initially configuring your ASA (or if you have the unfortunate pleasure of owning a PIX) to use an LDAP server.

So we're using LDAP so lets tell the ASA that: aaa-server Foobar_LDAP protocol ldap defines our server as Foobar_LDAP and specifies the protocol as LDAP .

Okay we told it a server exists, now we need to tell the ASA where to find it: aaa-server Foobar_LDAP (Internal) host 192.168.1.2 associates the Foobar_LDAP server we defines two seconds ago with the 192.168.1.2 IP address and lets the ASA know it's an internal server.

Then we specify the domain in which the server exists, foobar.com

And finally we give it the password, domain log-in, and tell the ASA that the server is running Windows.

aaa-server Foobar_LDAP protocol ldap
aaa-server Foobar_LDAP (Internal) host 192.168.1.2
 ldap-base-dn dc=foobar,dc=com
 ldap-group-base-dn dc=foobar,dc=com
 ldap-scope subtree
 ldap-naming-attribute saMAccountName
 ldap-login-password *****
 ldap-login-dn vpnasa@foobar.com
 server-type microsoft
 ldap-attribute-map LDAPAttMap

Implementing QoS on a GRE tunnel

Every night at a client location, we receive disconnects and an inability to run our capture configuration. Apparently they run a massive file backup which cannot be turned off. We decided to implement QoS (Quality of Service) on the tunnel in an attempt to not be disconnected. This was a one time deal so I doubt anyone will have to do this exact implementation again but hopefully this will unconfuse you when it comes to how QoS works.

QoS is basically traffic shaping; I'm not going to go in depth into it because I know less than I probably should considering I'm writing a wiki about it...We're giving priority to certain traffic when the packets are queued outbound.

It works somewhat differently with tunnels because we need to have the packet headers inspected BEFORE encapsulation. To do this we have to declare qos pre-classify; what this does is it creates a copy of the packet and caches it, encapsulates the packet, then when it comes to apply the QoS settings, it refers to the copy rather than the outbound packet itself.

Atlas

The first thing we have to do is define a class-map. Class maps identify traffic flows using a wide array of filtering criteria which are individually defined by match statements within the class map. Multiple match statements can be defined under a single class map.

When multiple match statements are used, the class map can be specified as follows:
match-all - a logical AND operand, meaning that all match statements must be true at the same time for the class map condition to be true
match-any - a logical OR operand, meaning that any of the match statements can be true for the class map condition to be true

You can define the follow criteria to match:

  access-group         Access group
  any                  Any packets
  class-map            Class map
  cos                  IEEE 802.1Q/ISL class of service/user priority values
  destination-address  Destination address
  discard-class        Discard behavior identifier
  dscp                 Match DSCP in IP(v4) and IPv6 packets
  flow                 Flow based QoS parameters
  fr-de                Match on Frame-relay DE bit
  fr-dlci              Match on fr-dlci
  input-interface      Select an input interface to match
  ip                   IP specific values
  mpls                 Multi Protocol Label Switching specific values
  not                  Negate this match result
  packet               Layer 3 Packet length
  precedence           Match Precedence in IP(v4) and IPv6 packets
  protocol             Protocol
  qos-group            Qos-group
  source-address       Source address
  vlan                 VLANs to match

For this specific scenario, we're concerned about SNMP and Telnet traffic:

class-map match-any CM-MANAGE
 match protocol snmp
 match protocol telnet

The next map you'll have to define is the first of two policy-maps. A policy map defines a named object that represents a set of policies to be applied to a set of traffic classes. There's two types of classes you can use, one such as our MANAGE class we defined earlier, and class-default which is the system default class matching otherwise unclassified packets. For our child policy map, we need to use a user-defined class.

Once in place, we can enforce a number of things:

  bandwidth        Bandwidth
  compression      Activate Compression
  drop             Drop all packets
  exit             Exit from class action configuration mode
  fair-queue       Enable Flow-based Fair Queuing in this Class
  log              Log IPv4 and ARP packets
  netflow-sampler  NetFlow action
  no               Negate or set default values of a command
  police           Police
  priority         Strict Scheduling Priority for this Class
  queue-limit      Queue Max Threshold for Tail Drop
  random-detect    Enable Random Early Detection as drop policy
  service-policy   Configure QoS Service Policy
  set              Set QoS values
  shape            Traffic Shaping

Our implementation is farily simple, so we're just giving our SNMP and Telnet traffic a priority. When defining priority, you can specify Kbps or percentage of total bandwidth. For us, we're just giving our traffic a 50Kb window.

policy-map PM-QOS-CHILD
 class MANAGE
  priority 50

For our next map, our parent map, we need to use the class-default class. As noted before, this matches unclassified packets. Within this class, we can refer to our CHILD policy map and implement traffic shaping. We could have implemented policing; policing also puts a limit on the maximum amount of available bandwidth, however, it simply drops off any packets that go over the set limit. Whereas shaping (which we're using here) will queue the traffic, cramming as many packets as possible within the limit given.

Because QoS on tunnels can only be applied ingress, we shape for the maximum upload rate provided by the ISP; in this case it's 500000bps (488Kbps). We also have to declare our child policy we defined earlier. The reason being is you cannot apply LLQ to the default class.

Low Latency Queuing (LLQ) allows delay-sensitive data to be given preferential treatment over other traffic by letting the data to be dequeued and sent first. 

policy-map PM-QOS-PARENT
 class class-default
  shape average 500000
  service-policy PM-QOS-CHILD

Now that we've drawn up our maps, we can apply them to our tunnel interface. Remember that we have to enable pre-classification to the interface otherwise our packets will be filtered after encapsulation.

int tun0
 service-policy output PM-QOS-PARENT
 qos pre-classify

Show

To verify that our QoS setup is working, we can use the show policy-map int tun0 command (replace tun0 with whatever interface you're applying it to).

You'll have to let some appropriate traffic through before this will accumulate any data; for our purpose, I simply spammed the inside with SNMP packets.

The main things we want to look for is any dropped packets, as you can see below there are none at the moment. We also want to make sure that our class-map is matching traffic; if you look under the user-defined class-map you will see a packet count. If this any anywhere higher than zero, it means your traffic is being matched and your QoS should be working.

Tunnel0 

  Service-policy output: PM-QOS-PARENT

    Class-map: class-default (match-any)
      2566 packets, 1453477 bytes
      5 minute offered rate 11000 bps, drop rate 0 bps
      Match: any 
      Queueing
      queue limit 64 packets
      (queue depth/total drops/no-buffer drops) 0/0/0
      (pkts output/bytes output) 0/0
      shape (average) cir 500000, bc 131250, be 131250
      target shape rate 500000

      Service-policy : PM-QOS-CHILD

        queue stats for all priority classes:
          
          queue limit 64 packets
          (queue depth/total drops/no-buffer drops) 0/0/0
          (pkts output/bytes output) 0/0

        Class-map: CM-MANAGE (match-any)
          157 packets, 110875 bytes
          5 minute offered rate 11000 bps, drop rate 0 bps
          Match: protocol snmp
            66 packets, 100848 bytes
            5 minute rate 11000 bps
          Match: protocol telnet
            91 packets, 10027 bytes
            5 minute rate 0 bps
          Priority: 50 kbps, burst bytes 1500, b/w exceed drops: 0
          

        Class-map: class-default (match-any)
          2409 packets, 1342602 bytes
          5 minute offered rate 0 bps, drop rate 0 bps
          Match: any 
          
          queue limit 64 packets
          (queue depth/total drops/no-buffer drops) 0/0/0
          (pkts output/bytes output) 0/0