The Cisco 3800 Router has two physical interfaces which are GigabitEthernet0/0 and GigabitEthernet0/1.  The interfaces are configured as follows:

The Firewall Inspect Policy is a set of rules or protocols that are scanned by the Router.  It verifies that traffic sent comes from the same source when receiving.  If you go to www.google.com, you only want www.google.com to respond.  It also assists with blocking attacks, such as a Denial of Service attack.

Prior to the problems we were experiencing, we had the following inspection policies configured:

ip inspect name cuseeme

ip inspect name dns

ip inspect name ftp

ip inspect name http

ip inspect name https

ip inspect name icmp

ip inspect name imap

ip inspect name pop3

ip inspect name netshow

ip inspect name rcmd

ip inspect name realaudio

ip inspect name rtsp

ip inspect name esmtp

ip inspect name sqlnet

ip inspect name streamworks

ip inspect name tftp

ip inspect name tcp

ip inspect name udp

ip inspect name vdolive

ip inspect name h323

In the beginning troubleshooting stages, I removed inspection rules one by one, hoping that one of these were at fault.  I then attempted to remove all inspection from the router which still did not solve the problem.  During one of my maintenance cycles I downgraded to an older ‘General Development’ Cisco 3800 Routers IOS version.  After that version downgrade and removing the Inspect Policies, we were then able to establish traffic for more than 1 hour.  Once I enabled inspection on the outside interface, we were unable to stay connected for more than 1 hour.

So why?

During the connection process with a Polycom, there is a ‘heart beat’ signal sent from the Polycom that answered the call to the Polycom that initiated the call.  I couldn’t find anything in any documentation because Polycom had one document that would corrupt when they emailed it and it couldn’t be found online.  After doing some traffic analysis, I discovered that every hour a TCP package is sent to and from the Polycoms.  Up until this point of the video call, all communication protocols have been UDP, the Polycoms have yet to communicate on any TCP Protocol.  I thought initially, removing TCP inspection on the Outside interface would solve this, but I was wrong.  This ‘heart beat’ package was anywhere from TPC port 4000 to 8000, and you never really knew for certain where it was going to come from.  If that ‘heart beat’ was not received at either end, the session would drop.

I now have the Cisco 3800 Router configured as follows:

One inspection rule for the Administration VLAN 100, one for the Campus VLAN 101, and one for the DMZ VLAN 102.  Notice I do not have an Inspection Policy in place for the Polycom/Video VLAN 103.  This seems has been working and was the last major configuration change made.  After making this change to allow for the ‘heart beat’ to communicate, everything has stayed connected past the 1 hour mark.

I do have some fears about the Outside interface being vulnerable to certain types of attacks that may saturate the interface and have taken measures to protect that from happening.  Those changes did not seem to affect the Polycom communication.  I am constantly running a ‘Show Memory Usage’ and ‘Show CPU Usage’ commands, if I have a second or two of downtime, I SSH into the router and check it.  I’ve been pleased with those statistics so far.

Also as a side note, while I had all Inspection disabled, we ran tests on the problem with Outlook disconnecting.  That did not resolve the issue.  Now I believe Heath has a workstation configured on the Video VLAN, which is essentially no access list (other than blocking telnet), and no inspection.  Wide open access.