[c-nsp] ASA bug?

[Greg Whynott]

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.


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.    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.  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.

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.