[c-nsp] ASA bug?

Tue Jan 25 14:52:32 EST 2011

Hi Greg,

Please see inline...

Greg Whynott wrote:
> Hi David,  i seen that after i sent the original email and took a chance no one would notice.  the telnet command was using 443,  not 80.  I was trying them both and doing some copy/pasting from the terminal whilst putting the email together.  my bad,  sorry for the confusion.
>   
Ok, no worries.
>
> from a machine on the internet (the "outside" interface),   the telnet x.x.x.x 443 was issued.  the policy applied to the outside interface would of dropped this packet.   the bug I'm reporting is we see what appears to be the "dropped" traffic egressing the dmz interface. 
OK, before we make this jump, let's validate a few things.

1) issue "show access-list" (you can filter this), and validate if you
see the hitcnt incrementing each time you issue the telnet.  If it is
not (which I suspect it is not), then the packet is not matching on this
line.  If the packet is matching on this line, then you wouldn't see it
in a DMZ capture.

2) Issue a packet-tracer command for this flow, and see what ACEs it
says the packet is matching.  Is it being denied by the ACE you want it to?

>    we should not see this as it was dropped at the outside interface and should never of made it this far.
>
> even tho we see the capture indicating packets were being sent out onto the wire,  this isn't the case.
For the capture command, it will capture the packet when it is forwarded
to the egress interface.  It is possible that the packet still doesn't
make it out on the wire.  For example, if there is no L2 address or L3
route (if needed) then the packet would not be forwarded on the wire. 
Creating a capture of type 'asp-drop' would indicate if the packet was
being dropped prior to actually egressing the interface.  Can you apply
an asp-drop capture (matching 'any' reason) and see if you are capturing
the packets there?  Since I don't notice any SYN+ACKs coming back to the
ASA, that would also partially indicate that perhaps the SYN packet
wasn't egressing the interface.

>   the target machine in that zone while running tcpdump does not see any packets arriving from the firewall for these connection attempts,  hence the reason we don't see any reply acks.  (no local OS firewalls running)
>
> hope that clears things.
>
> I  have the text buffers from the entire terminal sessions,  went over it again to make sure i wasn't making any silly mistakes.  it seems like this was what was actually happening..  i'm going to see if i can test this same zone again as we won't go live with it for another week or so.. failing that I'll uncrate the other 5540 and do a verbatim config on it in an effort to reproduce.
>   
We shouldn't have to go that far :-)  This should be a pretty easy
problem to solve.  Let me know what you see from the above, and we can
go from there.

Sincerely,

David.
> take care,
> greg
>
>
>
> On Jan 25, 2011, at 2:03 PM, David White, Jr. (dwhitejr) wrote:
>
>   
>> <snip>
>>     
>>> from an internet host I attempt a connection to port 80:
>>>
>>>
>>> ggw at 76.65.229.23:~$  telnet x.x.x.x 80
>>>
>>>
>>> I see the packets egress the newdmz interface:
>>>
>>>   1: 15:55:11.839525 802.1Q vlan#560 P0 x.x.x.x.2716 > 192.168.53.19.1433: . 3365025458:3365025459(1) ack 2402449091 win 64453
>>>   2: 15:55:11.840303 802.1Q vlan#560 P0 192.168.53.19.1433 > x.x.x.x.2716: . ack 3365025459 win 64374
>>>   3: 15:55:12.070079 802.1Q vlan#560 P0 192.168.53.19.1433 > x.x.x.x.2716: . 2402449090:2402449091(1) ack 3365025459 win 64374
>>>   4: 15:55:12.070202 802.1Q vlan#560 P0 x.x.x.x.2716 > 192.168.53.19.1433: . ack 2402449091 win 64453
>>>   5: 15:55:21.180608 76.65.229.23.61388 > x.x.x.x.443: S 2533989180:2533989180(0) win 65535 <mss 1260,nop,nop,sackOK>
>>>   6: 15:55:24.070659 76.65.229.23.61388 > x.x.x.x.443: S 2533989180:2533989180(0) win 65535 <mss 1260,nop,nop,sackOK>
>>>   7: 15:55:30.085978 76.65.229.23.61388 > x.x.x.x.443: S 2533989180:2533989180(0) win 65535 <mss 1260,nop,nop,sackOK>
>>>
>>>
>>> I see packets egressing the dmz interface into the dmz zone...    In my mind this is not a firewall issue as the packets are being forwarded into the zone,  as expected.
>>>
>>>       
>> But the traffic you captured is NOT the telnet to port 80 session. Are
>> you translating the port somewhere upstream before it reaches the ASA?
>> Or are you translating on the ASA?
>>
>>     
>>> the reality is there was a "deny ip any any into newzone" applied to the outside interface.
>>>       
>> If the 'deny' statement was applied inbound on the outside interface,
>> and this was also where the connection was initiating from, then yes -
>> traffic would have been denied. Note that if the telnet was initiated
>> from the dmz interface, then the ACL would not have blocked it.
>>
>> Sincerely,
>>
>> David.
>>     
>>> I should not of seen these packets when running a capture on the dmz interface, correct?  this caused me to spin my wheels on this for 1/2 a day till I noticed the acl in the outside_in section...
>>>
>>> soon as I removed the acl element from the outside_in,  things worked..
>>>
>>>
>>> am I not understanding something here or does this look wrong?
>>>
>>> thanks for your time,
>>> greg
>>>
>>>
>>> --
>>>
>>> This message and any attachments may contain confidential and/or privileged information for the sole use of the intended recipient. Any review or distribution by anyone other than the person for whom it was originally intended is strictly prohibited. If you have received this message in error, please contact the sender and delete all copies. Opinions, conclusions or other information contained in this message may not be that of the organization.
>>>
>>> _______________________________________________
>>> 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/
>>>
>>>       
>
>
> --
>
> This message and any attachments may contain confidential and/or privileged information for the sole use of the intended recipient. Any review or distribution by anyone other than the person for whom it was originally intended is strictly prohibited. If you have received this message in error, please contact the sender and delete all copies. Opinions, conclusions or other information contained in this message may not be that of the organization.
>   