ayourtch at gmail
Jul 2, 2008, 2:19 AM
Post #3 of 3
(457 views)
Permalink
|
|
Re: Capture expressions on an FWSM (was Re: Telnet FROM a PIX Appliance?)
[In reply to]
|
|
On Tue, Jul 1, 2008 at 6:06 PM, Higham, Josh <jhigham[at]epri.com> wrote:
>> 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?
it's useful to make a distinction between the FWSM and ASA.
FWSM has a few distinct components - fast path, session path, and
control plane.
The bulk of the traffic goes over a fast path (separate chips), and
the capture is
accumulated on the control plane.
While this sounds easy, in reality there are a lot of different
scenarios to account for -
and not all of them were caught the first time. Generally in 3.1.9 I
have found it to be
reasonably reliable - but I still tend to apply the same principle as
you when it comes
to "tricky" scenarios where the packets are absent - that I try to
doublecheck to ensure
there is no mistake made.
The capture on the FWSM should work similar to ASA's - with the
obvious caveat that since the packets are collected on the control
plane, the timing might be a bit off - so for time-sensitive scenarios
I'd still advise the span (by the way, the absence of the packets
there is also not a proof that the packet did not exist :-) - keep in
mind the DEC field notice.
The descriptions for the fixes within the capture component should be
coming up within the normal release notes - as for everything else.
Now, the ASA is purely software, which makes things a lot easier. To
me the only issue
that readily comes to mind is CSCsh89784. The code is pretty early in
the packet path,
so the only reason I can see is that there was some issue at a lower
level - the NIC driver.
But then the tweaks with the xlate on the other hand should not have
changed anything...
If you're able to make this behaviour happen at will, please drop me an email.
thanks,
andrew
>
> 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
>> >
>>
>>
> _______________________________________________
> 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/
|
