[c-nsp] H323 and ASA (over my head...)

Sun Aug 15 12:00:44 EDT 2010

Another alternative,
as a quick fix you can try to turn off H.323 inspection and see
whether it solved the issue. Welcome to the world of L7

-pavel

On Sat, Aug 14, 2010 at 11:58 PM, Pete Lumbis <alumbis at gmail.com> wrote:
> This could be anything from a non-standard H.323 stack to a bug in ASA code.
>
>
> Closed by inspection is when the h.323 inspection engine that is responsible
> for opening the high ports that are negotiated in the h.323 setup as well as
> NATing any addresses inside the h.323 packet closes the connection it is
> monitoring. Normally if an inspection engine closes down any part of a flow
> it will tear don any child flows (that is, flows opened by or opened for
> some setup type message).
>
> It's hard to tell exactly what caused the tear down, but I'd suggest you run
> the latest version of code for your ASA train (a number of voice/video
> related bugs have been fixed over the years). For more information I believe
> there is a "debug h323" command. I'd also suggest doing inside and outside
> captures on a circular buffer to try and see what is the last packet to make
> it through and if there is something fishy about it.
>
> Finally you can always call TAC they are pretty good about identifying why
> things like this happens, but you will probably need to be able to recreate
> the problem somehow so they can collect data.
>
> Hope this helps.
>
> -Pete
>
> On Sat, Aug 14, 2010 at 3:36 PM, Jeff Kell <jeff-kell at utc.edu> wrote:
>
>>  I have had several intermittent reports over time from one of our
>> distance learning customers concerning network issues during some of
>> their classes (appears to be just one classroom, with one particular
>> peer location, but I'm still looking to point the finger).
>> I'm way over my head with H.323 (do well to spell it)... other that
>> setting it up with default inspection.
>>
>> The classroom is setup on static NAT, and has a "permit ip any any"
>> policy on it with the peer addresses, as do our other codecs.
>>
>> The call was done outbound, and the ASA "associated setup" appears to
>> have succeeded:
>>
>> Original setup 323:
>> > Aug 14 08:01:47 ASA %ASA-6-302013: Built outbound TCP connection
>> > 100295465 for outside:remote-site/1720 (remote-site/1720) to
>> > legacy:inside-codec/5555 (EX-inside-codec/5555)
>>
>> And associated:
>> > Aug 14 08:01:51 %ASA-6-302003: Built H245 connection for faddr
>> > inside-codec laddr remote-site/11014
>> > Aug 14 08:01:51 %ASA-6-302003: Built H245 connection for faddr
>> > inside-codec laddr remote-site/11014
>> > Aug 14 08:01:52 %ASA-6-302004: Pre-allocate H323 UDP backconnection
>> > for faddr remote-site to laddr inside-codec/2326
>> > Aug 14 08:01:52 %ASA-6-302004: Pre-allocate H323 UDP backconnection
>> > for faddr remote-site to laddr inside-codec/2327
>> > Aug 14 08:01:53 %ASA-6-302004: Pre-allocate H323 UDP backconnection
>> > for faddr remote-site to laddr inside-codec/2328
>> > Aug 14 08:01:53 %ASA-6-302004: Pre-allocate H323 UDP backconnection
>> > for faddr remote-site to laddr inside-codec/2329
>> > Aug 14 08:01:53 %ASA-6-302004: Pre-allocate H323 UDP backconnection
>> > for faddr remote-site to laddr inside-codec/2330
>> > Aug 14 08:01:53 %ASA-6-302004: Pre-allocate H323 UDP backconnection
>> > for faddr remote-site to laddr inside-codec/2331
>>
>> > Aug 14 08:01:52 %ASA-6-302013: Built outbound TCP connection 100295645
>> > for outside:remote-site/11014 (remote-site/11014) to
>> > legacy:inside-codec/5556 (EX-inside-codec/5556)
>>
>> But about an hour into the call, there was this "odd" sequence of events
>> (particularly the "closed by inspection" bit):
>>
>> > Aug 14 09:02:36 %ASA-6-302014: Teardown TCP connection 100295645 for
>> > outside:remote-site/11014 to legacy:inside-codec/5556 duration 1:00:45
>> > bytes 6223 Flow closed by inspection
>> > Aug 14 09:02:36 %ASA-6-302016: Teardown UDP connection 100295706 for
>> > outside:remote-site/2445 to legacy:inside-codec/2331 duration 1:00:40
>> > bytes 94208
>> > Aug 14 09:02:36 %ASA-6-302016: Teardown UDP connection 100295703 for
>> > outside:remote-site/2444 to legacy:inside-codec/2330 duration 1:00:44
>> > bytes 402
>> > Aug 14 09:02:36 %ASA-6-302016: Teardown UDP connection 100295695 for
>> > outside:remote-site/2441 to legacy:inside-codec/2329 duration 1:00:42
>> > bytes 111168
>> > Aug 14 09:02:36 %ASA-6-302016: Teardown UDP connection 100295693 for
>> > outside:remote-site/2440 to legacy:inside-codec/2336 duration 1:00:44
>> > bytes 158138102
>> > Aug 14 09:02:36 %ASA-6-302016: Teardown UDP connection 100295692 for
>> > outside:remote-site/2440 to legacy:inside-codec/2328 duration 1:00:44
>> > bytes 198963714
>> > Aug 14 09:02:36 %ASA-6-302016: Teardown UDP connection 100295688 for
>> > outside:remote-site/2439 to legacy:inside-codec/2327 duration 1:00:41
>> > bytes 112048
>> > Aug 14 09:02:36 %ASA-6-302016: Teardown UDP connection 100295686 for
>> > outside:remote-site/2438 to legacy:inside-codec/2334 duration 1:00:44
>> > bytes 30243540
>> > Aug 14 09:02:36 %ASA-6-302016: Teardown UDP connection 100295685 for
>> > outside:remote-site/2438 to legacy:inside-codec/2326 duration 1:00:44
>> > bytes 31335820
>> > Aug 14 09:02:36 %ASA-6-302015: Built inbound UDP connection 100675685
>> > for outside:remote-site/2440 (remote-site/2440) to
>> > legacy:inside-codec/2328 (EX-inside-codec/2328)
>> > Aug 14 09:02:36 %ASA-6-302015: Built inbound UDP connection 100675686
>> > for outside:remote-site/2438 (remote-site/2438) to
>> > legacy:inside-codec/2326 (EX-inside-codec/2326)
>> > Aug 14 09:02:36 %ASA-6-302015: Built outbound UDP connection 100675688
>> > for outside:remote-site/2440 (remote-site/2440) to
>> > legacy:inside-codec/2336 (EX-inside-codec/2336)
>> > Aug 14 09:02:36 %ASA-6-302015: Built outbound UDP connection 100675689
>> > for outside:remote-site/2438 (remote-site/2438) to
>> > legacy:inside-codec/2334 (EX-inside-codec/2334)
>>
>> It appears that the "inspection" closed out the call (and the
>> back-channel traffic), while the channels continued to pass data (the
>> connections built afterward using the same src/dst ports).  The call
>> could not however be re-established.
>>
>> Can anyone explain this "closed by inspection" bit?  Is that the "cause"
>> of the call termination/interruption, or is it an "effect" of an
>> incident on the other end?
>>
>> Thanks in advance,
>>
>> Jeff
>>
>>
>> _______________________________________________
>> cisco-nsp mailing list  cisco-nsp at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-nsp
>> archive at http://puck.nether.net/pipermail/cisco-nsp/
>>
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>