[Answered] Video Conferencing disconnecting after 45 seconds

[eric.schewe]

Resolution found. See my last post since I can't mark one of my own replies as the answer.

I've got a Cisco PIX 515 running 8.0(4)28. I just installed a new LifeSize video conferencing unit with a static NAT mapping to a public IP address and configured the LifeSize to properly utalize a static NAT translation.

I can dial out and anyone can dial in to me but after 45 seconds in the call it drops. Always 45 seconds on the dot. We can also see some packetloss during the call but near as I can tell I am not experiencing any packet loss internal or external to my network. I've tried calling multiple destinations and have the same problem.

I've opened the appropriate ports on my firewall and I've even tried a simple "any/any ip allow" but inbound and outbound for the video conferencing unit. No change.

Attached is a sanatized log of an entire session.

The line that jumps out at me as the problem is this one:

2013-02-16T20:08:45.132786-08:00 Feb 16 2013 20:08:45 515-pix-core : %PIX-6-302014: Teardown TCP connection 1016 for outside:xxx.xxx.xxx.xxx/0 to outside:50.59.87.246/60349 duration 0:00:30 bytes 0 Pinhole timeout

But I'm only guessing at this point. Any help would be appreciated.

[eric.schewe]

Oh and I should mention that 50.59.87.246 = demo.lifesize.com which is who I was calling to test the connection.

[Jouni Forss]

Hi,

I'm not sure if I can help with this but I'll answer anyway

Here is the explanation for that connection Teardown message

Pinhole Timeout

Counter is incremented to report that the appliance opened a secondary  flow, but no packets passed through this flow within the timeout  interval, and hence it was removed. An example of a secondary flow is  the FTP data channel that is created after successful negotiation on the  FTP control channel.

Source:

http://www.cisco.com/en/US/docs/security/asa/asa80/system/message/logmsgs.html#wp4770614

The logs seem to show that the connection is first formed through the destination port TCP/1720 which I guess corresponds a Control connection when using FTP. I guess this connection is always formed when a call is made. After that I've usually seen a secondary TCP connection being formed and finally several UDP connections for the video/voice (If I'm correct that is)

It seems to me that possibly all that is done but then one of the TCP connections just timeouts because of no Data and after that all the rest of the connections get torn down and you continue to see traffic for those connections.

The logs also show several messages that point to a situation that the connections have been already removed by the PIX and there is still traffic coming for the said connection which then gets blocked by the PIX as it doesnt have the connection anymore. (no connection) -messages.

Video/Voice are again a subject that I know very little about.

I think we have the same brand equipment ourselves compared to the one you are testing at the moment.

For test purposes (If possible) I would perhaps first look into removing all the "inspect" configurations related to the video/voice. You would though probably need to permit alot of traffic between the hosts for this connection after that.

There is also the possiblity of configuring different rules for certain connections. For example reconfigure their timeouts etc.

I'm not sure if this could be some PIX software related thing. Naturally in this case your possibilities are kind of slim as to my knowledge the PIX cant get much higher than that in software. Think 8.0 already was pushing the limits of memory usage atleast.

- Jouni

[eric.schewe]

Thanks for the help. I did try removing the 'inspect' configurations and it didn't help.

Turns out it's a known issue with Satallite Internet Connections, Cisco PIX/ASA Firewalls and LifeSize.

See: http://videocenter.demo.lifesize.com/videos/video/20195

[eric.schewe]

Well now that's powerful dumb. I can't mark one of my replies as the answer!?