[c-nsp] Capture expressions on an FWSM (was Re: Telnet FROM a PIX Appliance?)

[Higham, Josh]

> Tony Varriale wrote:
> > Any chance you could give the group more details before saying it 
> > can't be trusted?
> >
> I'm afraid I don't have any concrete details to add, but I've found 
> capture expressions on Firewall Service Modules to be quite 
> inconsistent. Presumably this is something to do with the modules 
> interaction with the chassis? I haven't had the time to lab 
> this, and I 
> haven't always had problems, but I now generally work to the 
> mantra that 
> "the absence of a packet in an FWSM capture is not proof that 
> the packet 
> does not exist, but the presence of a packet in a capture does prove 
> it's existence".
> 
> Perhaps there is a cisco documentation on this, listing known caveats 
> and limitations?

I found the same situation with the ASA (version 8.0 code).  Normally
you would expect the packet capture to be the very first code path, but
this is demonstrably not true.  In my case I had a span port on a switch
and would get the packet, but a capture on the firewall did not show it.

"The absence of a packet is not proof that the packet doesn't exist"

Thanks,
Josh

> > ----- Original Message ----- From: "Higham, Josh" <jhigham at epri.com>
> > To: <cisco-nsp at puck.nether.net>
> > Sent: Monday, June 30, 2008 10:41 AM
> > Subject: Re: [c-nsp] Telnet FROM a PIX Appliance?
> >
> >
> >>> [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Ziv Leyes
> >>>
> >>> I guess it's more as a "working right" educational purpose,
> >>> so you won't use your firewall as a debugging client.
> >>> In newer versions there's the packet tracker that can help
> >>> you debug connectivity problems.
> >>> Ziv
> >>
> >> As an FYI, the ASA/Pix packet capture cannot currently be 
> completely
> >> trusted (version 8.0).  I found an annoying bug where I 
> would capture
> >> the frame on a span session monitoring the port connected to the
> >> firewall, but it wouldn't show up on the firewall capture.
> >>
> >> The packet in question was also being dropped by the 
> firewall, but with
> >> no logging (and with a permit ip any any rule in place).  
> The 'fix' was
> >> to apply a nat translation and then remove it.  TAC was completely
> >> unhelpful (worst ever TAC experience).
> >>
> >> Blocking outbound sessions on the firewall also means that 
> it can't be
> >> used to bounce an attack, if compromised.
> >>
> >> Thanks,
> >> Josh
> >
> 
>