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

Sat Aug 14 17:58:05 EDT 2010

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 down 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/
>