Recently, I was tasked with implementing Websense to help monitor the activities of our user base in LA and NY.  After a few discussions with the Websense sales engineers, I came up with a design to utilize the ASA firewalls in both my locations.

The Websense components were installed as follows:

For the filters:

User Service - This service identifies the users, groups, and domains within Windows Active Directory.

Filtering Service - This is the service that will monitor or block content.

Network Agent - This component is how the server will communicate with the Policy Server.

DC Agent - This service integrates AD authentication for end users who don’t want to be filtered.

Usage Monitor - This service collects usage information based on categories, protocols, etc.

For the manager:

Policy Database - Microsoft SQL is required to store your database.

Policy Broker - This service updates the filter servers whenever a change is made to the policy.

Policy Server - This service provides policy management.

Websense Manager - This service allows you to manage your filters.

Log Server - This service collects the logs off the filters for reporting.

The Websense engineers recommended that I install the Policy Broker, Server, and Database on one of the filter server.  I felt it didn’t make sense to add the bulk of the processing power to a dedicated filter box.  Plus, I’d rather have all the management components reside on a central server.

During my initial install of each of the filters, I only had one network card enabled.  Also, for some odd reason I was unable to set up ‘integrated’ mode and was forced to install each filter as ’stand-alone’ devices.  Integrated mode allows you tie in with your ASA firewall, but can only filter http, https, or ftp.  Here are the commands I used:

url-server (inside) vendor websense host 11.27.194.44 timeout 30 protocol TCP version 4 connections 5
filter https 443 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 allow
filter url http 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 allow
url-block url-mempool 1500 –> Recommended configuration from Websense.
url-block url-size 4 –> Recommended configuration from Websense.

Even though I was running in stand-alone mode, I was still able to run the ASA firewall commands and the filter started working.  This particular setup ran for about a week until we had to move a new group who seem to have had stringent requirements for their web surfing activities.  What it boiled down to was they weren’t very pleased with the fact that our Internet connection was monitored and filtered.

Our LA filter was performing just fine, but our NY filter where the new group resided was extremely slow.  There were complaints that simple websites would take anywhere between 10-60+ seconds to load.  To troubleshoot the performance problem, I verified performance to/from the intermediate switches, core routers, and firewalls which all checked out fine.  The design I had built took into account that there were 150 end-users combined from both locations and the Websense engineers validated that the integration with our firewalls was sufficient.  After verifying the network, I had contacted the sales engineer to engage their support.

Websense support noticed I wasn’t running integrated mode properly and walked me through updating each filter.  Once we were fully integrated, the performance for NY suffered even more to the point that web pages were taking minutes to load.  So now I started questioning whether or not the integrated mode could support a handful of users.  Websense’s documentation clearly states that the integrated mode with an ASA firewall can easily support up 250+ users which was obviously not the case.

I had to engage support yet again and was told to run each filter in stand-alone mode, activate the second network card on the filters, and SPAN the data to the second NIC.  Websense support clearly stated that RSPAN doesn’t work with their product and that it was unsupported.  To the set the record straight, RSPAN does work with Websense.  You just have to figure out the IOS configuration because most of Cisco’s documentation still refers to the ‘reflector-port’ option which doesn’t run on 3560s or 3750s.

My ASA inside interface in LA was configured as a trunk on port Gi1/0/3 on SW11; nothing special needed to be configured on the trunk port where the firewall was connected.  Here’s my configuration on SW11:

vlan 888 –> This vlan number should be lower than 1000.  I tried 1888, but that didn’t seem to work.
name RSPAN-ASA-INSIDE
remote-span

interface vlan 888 –> A ’show interface’ will reveal that the line protocol is down, which is fine.
no shutdown

monitor session 1 source vlan 8 –> Using ’source interface gi 1/0/3′ didn’t work for me.
monitor session 1 destination remote vlan 888

interface GigabitEthernet1/0/25
description CONNECTED-TO-SW13-G0/24
switchport trunk allowed vlan add 888 –> I do this because I specifically allow certain VLANs across the trunk.

Here’s my configuration on SW13:

vlan 888
name RSPAN-ASA-INSIDE
remote-span

interface vlan 888
no shutdown

interface GigabitEthernet0/24
description CONNECTED-TO-SW11-G1/0/25
switchport trunk allowed vlan add 888

monitor session 1 source remote vlan 888
monitor session 1 destination interface Gi0/22 encapsulation dot1q ingress untagged vlan 8

Once I entered the destination interface, my stand-alone LA filter started seeing all the protocols.  The performance appeared to be much better and can supposedly handle up to 1200+ users.  I’ve excluded the new groups from being filtered for the time being and have activated it for the rest of my group to validate the performance.  I’ll probably monitor the behavior over the long weekend before implementing entirely, but hopefully my performance problems are now behind me.

I wonder if it would’ve been easier to implement Cisco’s Ironport web filter??

When configuring EIGRP on the firewall, keep in mind to omit the word ip from the commands.

Prerequisites:

-Refer to my Basic ASA - VLANs and IP Addresses posting

Mini-lab Requirement:

Your ASA needs to be aware of the DMZ network behind R2.  Make sure R2 is the only device that can securely send or receive routing updates with the firewall.

Here’s the video:

bbb-basic-asa-eigrp

Notes:

-EIGRP is not supported in multi-context mode.

-When configuring the network command on a PIX or ASA, you will need to define the subnet mask and not the wildcard.

-The passive-interface command for EIGRP is supported on the firewall unlike OSPF.

A few weeks ago, Cisco released version 8.2 for the ASA, which you can read more about the updated features here.  For me, one of the most appealing features that stands out the most is the NetFlow Secure Event Logging feature (NSEL).   Originally this feature was only made available on version 8.1 specifically for the 5580 models in January of this year.  Now it’s available from the 5505 models up to the 5580.

What’s the big deal?  Currently I’m dealing with a configuration where an Internet connection terminates directly on an ASA 5520.  Every month I have to deal with senior management inquiring about which department is consuming the most bandwidth so that finance can appropriately charge back the usage internally.  In order to appropriately collect this data, I had proposed to place a router in front of the ASA so that I could collect NetFlow statistics and report the information properly.  With NSEL on the ASA, I’d be able to collect the information directly without any additional equipment.

Hmm, if everything works as planned, I’ll have to figure out what to do with all these spare 3845 edge routers. 

This is very similar to the last lab that I posted.  When configuring OSPF on the firewall, keep in mind to omit the word ip from the commands.

Prerequisites:

-Refer to my Basic ASA - VLANs and IP Addresses posting

Mini-lab Requirement:

Your ASA needs to be aware of the DMZ network behind R2.  Make sure R2 is the only device that can securely send or receive routing updates with the firewall.

Here’s the video:

bbb-basic-asa-ospf

Notes:

-OSPF is not supported in multi-context mode.

-When configuring the network command on a PIX or ASA, you will need to define the subnet mask and not the wildcard.

-The passive-interface command is unsupported on the firewall.  You will need to depend on the neighboring router to control sending/receiving of updates.

-If you would like to verify that you didn’t fat finger the password on the ASA, you can use the more system:running-config | i md5 command to see what you typed.