Time to blame the Firewall ….

Now, I knew that Cisco PIX  ‘fixup protocol smtp’ caused Exchange to suffer horribly until it was disabled, but couldn’t find any offical word on the ASA 8.21 doing the same.

We still had the ESMTP filter in place, as part of Cisco’s Modular Policy Framework . I removed the “inspect esmtp” statement from our global_policy map and instantly the problems disappeared.

CiscoAsa(config)#class inspection_default

CiscoAsa(config-pmap-c)# no inspect ESMTP

Hum Ho.

The complaints centred around http downloads being much slower before the ASA was deployed; In the case of FTP downloads, they were dropping out completely.

The rules and configuration were fine and the traffic throughput was at steady 10mb a second on the ASA. I had a flash back to my old CCNA training, so ran through the basic checks.

The simple show interface command to display information on each interface immediately displayed a problem. The internal interface had a massive amount of input errors and CRC’s

Ciscoasa# show interface

—-Snip—–

173687355 packets input, 58611585574 bytes, 0 no buffer

Received 892529 broadcasts, 0 runts, 0 giants

3301144 input errors, 3301144 CRC, 0 frame, 0 overrun, 0 ignored, 0

—-Snip—–

Now that’s a problem.

Both interfaces on the ASA had been set to speed 100, duplex full. A quick check on the switch connected to the internal ASA interface showed it was set to auto negotiate. By flipping the ASA’s interface to auto negotiate, the errors stopped dead.

Checked back with the users and the downloads were back to the normal 250kb/sec.

Sometimes, users can be useful for troubleshooting ….

Got everything working except for RSA authentication.

DNS forward and reverse entries were in place (if you don’t have a PTR record, the ACE server would not automatically resolve the FQDN) and the agent on the RSA windows ACE server was set up and set to all local user authenticate and everything seemed correct.

You need a successful authentication for the shared key to be pass to ASA, so tried to authenticate to ASA with a token and it failed.

On the RSA windows ACE server:

Securid Helpdesk Administrator – Report – Log Monitor – activity monitor set it to monitor the ASA.

node verification failed message was display at each authentication attempt.

We figured that the shared key wasn’t getting to the ASA but couldn’t find any obvious place to find it.

Then we dug out this gem:

(This is taken directly from the Ciscowiki)

I read about the .sdi file on the flash of an ASA. So what happens is on the first authentication, the RSA hands down an sdi file to the ASA and this becomes the shared key between the 2 devices.  Since the ASA had an existing key, .sdi file, the way to fix it was to simply delete the file(s).

ASA(config)# dir
Directory of disk0:/

6 drwx 8192 09:18:46 May 31 2008 crypto_archive
91 -rwx 14635008 03:08:24 Aug 12 2008 asa803-k8.bin
92 -rwx 6851212 03:10:56 Aug 12 2008 asdm-603.bin
2 drwx 8192 03:14:44 Aug 12 2008 log
93 -rwx 2153344 11:33:12 Aug 12 2008 anyconnect-win-2.2.0136-k9.pkg
99 -rwx 512 19:01:08 Aug 13 2008 10-100-1-20.sdi

ASA(config)# delete disk0:10-100-1-20.sdi

-Chop-

Removed the .sdi file and on the first authentication everything worked as expected.

Thanks anonymous Cisco-guy and THE Bundy!