The Silo Chronicles
The not so exciting adventures of a Network Engineer

With the release of 8.0.4 the ASAs now support a PhoneProxy functionality.  It seems that this news spread unusually fast within the management circles as more and more customers seem to be asking about the technology.  Last week I had a chance to sit down and get it working on a 5510 and figured I would send out a link that made it possible.  Of course Cisco has a technically accurate guide on their CCO site but like normal it lacks many useful explanations.  After poking around for a bit I found a wonderful guide on the Cisco Wiki.

http://supportwiki.cisco.com/ViewWiki/index.php/ASA_Phone_Proxy_sample_configuration

I found this very helpful in not just configuring but understanding exactly which of the configuration snippets discussed will be needed.  After following this guide I was able to get them up and running on the phone proxy in short order.  The only issue I ran into is for some reason when I pasted in the Manufacturer certificate it lost a few lines of it so I had to re-paste it.  Once I fixed that everything worked like a champ.

Now, I wish I could say all my experience have been like this.  The customer I got this working at has a very simple configuration on their 5510 and network in general.  I have since tried to set this up on three other ASAs and it seems to not have gone in quite so easy.  The problem seems to resolve around TFTPing during registration and timing out.  In all three cases everything goes great, phones upgrade, you see them in the PhoneProxy commands but once it tries to register the configuration transfers, says complete and then all the sudden it says “Received Packet # expected 1″ and promptly dies.  Unfortunately I am still waiting for some help from TAC to fix these so if you have any suggestions let me know!

I ran across a customer today that asked how exactly their CSA 6.0 was protecting them from Viruses.  I wasn’t able to find a pre-canned response for them so I put together a quick overview I thought I would share.

CAS deployed two detection methods for anti-virus protection.  You can run either one or both at the same time.  The first detection method is what most people are used to and that is a Signature based solution.  This solution uses the Clam AV engine and signatures.  The second is a Behavior Analysis.  This simply looks at the behavior of the file and determines if it thinks it is a virus or not.

When a file is flagged via either of these detection methods the file get “tagged” as a virus and becomes inplaced quarantined.  This is different from other solutions that physically move the file to a new location.  One of the reason CSA handles the virus infected file this way is that it will now monitor this file and any other file that might access this file.  This allows the system to try and detected secondary infected files.  Once a file is flagged CSA prevents all access to the file and fires off a deny event whenever an access attempt is made.  You can review these events to find outwhat other files are trying to access this infected file.

You can view the quarantined files by loading the CSA Agent GUI, clicking on Anti-Virus and then looking in the quarantined files section.  Files that are tagged via the signatures based detection are automatically deleted after 60 days by default where files that are tagged via the Behavior Analysis detection method are never automatically deleted.

You can determine which method was used to detect the virus by looking at the details of the event and viewing the first two lines.  It will tell you if it was a signature or behavior that triggered the event.

With the release of 8.0(4) the ASA now supports a nifty new feature called Phone Proxy. The concept behind this little feature is that now an IP Phone can register to the ASA which will proxy the communications to CallManager/CallManager Express. This allows the deployment of IP Phones without VPN tunnels and simplifies the remote deployment greatly.

We threw up 8.0(4) on a 5505 and then did a quick “show version” to confirm the new load and we found something that made our hearts sink.

UC Proxy Sessions is a licensed feature? We quickly contacted some SEs at Cisco who confirmed this is going to be a separately licensed feature. The best news is that don’t have any pricing information out for it nor have any ideas when they will start selling said licenses.

It doesn’t take a genius to determine why this is a separately licensed feature but all I hope is it a decent price and not some absorbent amount of money.

I first deployed a series of ASA5505s running 7.2 about six months ago and one of the things I noticed is that I was getting what seemed to be pre-mature NAT terminations. I would see PC A contact Server B, Server B send results back when all the sudden I would get a message about no translate for the PC A to Server B and then ACL denies for Server B to PC A on the former NAT port. I opened a TAC case at the time and was told this was working as expected.

Flash forward six months and many ASAs later including an upgrade to 8.0(3) and the problem still remains. This became more than just a nuisance with a recent deployment of CS-MARS. Suddenly we were getting inundated with incidents relating to these issues. I again went to TAC and they told me is was a non-issue. After pressing them some more and lots of packet capturing and testing we were able to narrow it down. The issue was relating to the following configurations:

As soon as I removed these lines the issue went away. The only thing left to dispute now is if this is a bug or working as intended. Obviously Cisco quickly says it is working as intended, which I find hard to believe. Either way if you run into this issue and want to correct it look for your threat-detection configuration and remove it. For a complete explanation of what these commands do visit:

http://www.cisco.com/en/US/docs/security/asa/asa80/command/reference/t.html#wp1462189

I noticed that my CS-MARS box was no longer auto-updating its IPS signatures so I figured I would take a look at it. I am using CCO to get my updates and it was working fine but we had changed the CCO password it was using a few weeks ago and I forgot to update it here. I typed the new password in, clicked Test Connectivity and got a rejected message. After clicking on More Info it says File Not Found.

It seems that somehow CS-MARS lost the certificate for the connection and when you click “Test Connectivity” that routine will not present the certificate to you. You must click the “Update Now” button to get presented with the new certificate. Once accepted the test works fine and all is well. The moral of this story is to not rely solely on “Test Connectivity”.

I received word back from Cisco on the issue I discovered last week between CS-MARS and IPS 6.1. It seems that CS-MARS is currently using RDEP protocol to perform the Test Connectivity function to Cisco IDS/IPS devices. Starting in IPS v6.1 RDEP is now disabled by default (it was replaced with SDEE starting in IDS 5.0/IPS 5.1). The reason the functionality of it still worked is that CS-MARS uses SDEE to pull data not RDEP.

The CS-MARS BU has flag this issue and said the fix for it will be released in 6.0.1. As a work around you can just ignore the Test Connectivity button or simply enable RDEP. To enable RDEP do the following:

I upgraded an IDSM-2 and an AIP-SSM-10 today to the new 6.1. Let me start by saying finally. They finally added an auto-update signatures from CCO. Along with the new release comes a new release of IME and wow is it spiffy. The purpose of this quick entry though isn’t to go one about how nice the new release is but instead give you a heads up to an issue I discovered.

There appears to be an issue with CS-MARS (5.3.4) integrating with the IPS 6.1 version. When you click test connectivity it will prompt you for a new certificate like normal but after clicking yes it will tell you it couldn’t talk to the sensor. The thing is that it is actually still talking to the sensor. I spoke with Cisco about it today and they were able to replicate the issue and acknowledge it is a bug and that it is cosmetic only.

I am not sure which CS-MARS versions are affected other than 5.3.4. Once they give me the BugID I will upset this post.

UPDATE: Bug ID CSCsq07003