Unstable RDP sessions

Adam David · ‎05-31-2010

Hi all,

User A can login into server B via RDP (tcp 3389) however he cannot copy the file from server B via remote desktop.He also can ping and do a traceroute to the server.

When I do a testing with him, I’ve found out the following message on ASA. This is the only message that I saw on the firewall. %ASA-2-106001: Inbound TCP connection denied from

ASA-fw# sh log | grep 1.1.1.1
Jun 01 2010 08:46:00 3.3.3.3 : %ASA-2-106001: Inbound TCP connection denied from 1.1.1.1/1852 to 2.2.2.2/3389 flags PSH ACK  on interface inside
Jun 01 2010 08:46:00 3.3.3.3 : %ASA-2-106001: Inbound TCP connection denied from 1.1.1.1/1852 to 2.2.2.2/3389 flags PSH ACK  on interface inside
Jun 01 2010 08:46:00 3.3.3.3 : %ASA-2-106001: Inbound TCP connection denied from 1.1.1.1/1852 to 2.2.2.2/3389 flags PSH ACK  on interface inside
Jun 01 2010 08:46:00 3.3.3.3 : %ASA-2-106001: Inbound TCP connection denied from 1.1.1.1/1852 to 2.2.2.2/3389 flags PSH ACK  on interface inside

Let say
User A = 1.1.1.1
Server B = 2.2.2.2
New Fw ASA = 3.3.3.3

Fw is allowed RDP connection from user A to Server B.Here are the rules on the firewall related to the server B.

object-group service Standard_Remote_Access                                                                                           
 service-object tcp eq telnet                                                                                                                 
 service-object tcp eq ssh                                                                                                                    
 service-object tcp eq https                                                                                                                  
 service-object tcp eq www                                                                                                                    
 service-object tcp eq 3389                                            

access-list acl-in extended permit object-group Standard_Remote_Access  any object-group Network_2.2.2.2_24

This problem only occured after New Fw ASA installed between the user A and server B. Any advice would be appreciated. Thanks

Marcin Latosiewicz · ‎06-01-2010

You'd need to get a sniffer trace for this exact traffic (ASA has "capture" command built in).

http://www.cisco.com/en/US/docs/security/asa/asa82/system/message/logmsgs.html#wp4768860

At minimum tell us what is the software versions of ASA and RDP server/client versions.

Adam David · ‎06-13-2010

Thanks Marcin for your suggestion.

RDP client version is 5.1(Build 2600), Control Version 5.1.2600.3627

RDPserver version is 5.2.3790.3959 <-- I'm not sure whether this is correct or not? May I know how to check the version of RDP server?

I did the packet capture and here is the result...

Packet 1-3: TCP Three way handshake

 1: 10:05:27.279373 1.1.1.1.5555 > 2.2.2.2.3389: S 945100646:945100646(0) win 64512 <[|tcp]> 
   2: 10:05:27.280381 2.2.2.2.3389 > 1.1.1.1.5555: S 2051713410:2051713410(0) ack 945100647 win 16384 <[|tcp]> 
   3: 10:05:27.280548 1.1.1.1.5555 > 2.2.2.2.3389: . ack 2051713411 win 64860

The next packet: Data transfer

   4: 10:05:27.280731 1.1.1.1.5555 > 2.2.2.2.3389: P 945100647:945100685(38) ack 2051713411 win 64860 
   5: 10:05:27.282273 2.2.2.2.3389 > 1.1.1.1.5555: P 2051713411:2051713422(11) ack 945100685 win 65497 
   6: 10:05:27.282517 1.1.1.1.5555 > 2.2.2.2.3389: P 945100685:945101097(412) ack 2051713422 win 64849 
   7: 10:05:27.283859 2.2.2.2.3389 > 1.1.1.1.5555: P 2051713422:2051713759(337) ack 945101097 win 65085 
   8: 10:05:27.284119 1.1.1.1.5555 > 2.2.2.2.3389: P 945101097:945101109(12) ack 2051713759 win 64512 
   9: 10:05:27.284164 1.1.1.1.5555 > 2.2.2.2.3389: P 945101109:945101117(8) ack 2051713759 win 64512 
  10: 10:05:27.284851 2.2.2.2.3389 > 1.1.1.1.5555: . ack 945101117 win 65065

Everything looks normal untill packet number 511. User sents a few PUSH packet to the server, but the server never reply.

511: 10:06:32.454215 1.1.1.1.5.5.5.5 > 2.2.2.2.3389: P 457295239:457295635(396) ack 3592134313 win 64860 
 512: 10:06:32.738258 1.1.1.1.5.5.5.5 > 2.2.2.2.3389: P 457295121:457295635(514) ack 3592134313 win 64860 
 513: 10:06:33.285156 1.1.1.1.5.5.5.5 > 2.2.2.2.3389: P 457295121:457295635(514) ack 3592134313 win 64860 
 514: 10:06:33.557145 1.1.1.1.5.5.5.5 > 2.2.2.2.3389: P 457295635:457295657(22) ack 3592134313 win 64860 
 515: 10:06:33.665981 1.1.1.1.5.5.5.5 > 2.2.2.2.3389: P 457295657:457295758(101) ack 3592134313 win 64860 
 516: 10:06:33.802158 1.1.1.1.5.5.5.5 > 2.2.2.2.3389: P 457295758:457295838(80) ack 3592134313 win 64860 
 517: 10:06:33.953869 1.1.1.1.5.5.5.5 > 2.2.2.2.3389: P 457295838:457295862(24) ack 3592134313 win 64860 
 518: 10:06:34.394739 1.1.1.1.5.5.5.5 > 2.2.2.2.3389: P 457295862:457295928(66) ack 3592134313 win 64860 
 519: 10:06:34.488256 1.1.1.1.5.5.5.5 > 2.2.2.2.3389: P 457295121:457295657(536) ack 3592134313 win 64860 
 520: 10:06:36.894423 1.1.1.1.5.5.5.5 > 2.2.2.2.3389: P 457295121:457295657(536) ack 3592134313 win 64860

At packet 521, suddently the server sent RESET packet to the user to terminate the connection

521: 10:06:36.894591 2.2.2.2.3389 > 1.1.1.1.5555: R 3592134313:3592134313(0) ack 457295657 win 64860

Packet 522-524, client try to re-establish the connection

 522: 10:06:36.919630 1.1.1.1.6666 > 2.2.2.2.3389: S 2294133377:2294133377(0) win 64512 <[|tcp]> 
 523: 10:06:36.920484 2.2.2.2.3389 > 1.1.1.1.6666: S 2704546546:2704546546(0) ack 2294133378 win 16384 <[|tcp]> 
 524: 10:06:36.920667 1.1.1.1.6666 > 2.2.2.2.3389: . ack 2704546547 win 64860

And communication re-created again..

 525: 10:06:36.920805 1.1.1.1.6666 > 2.2.2.2.3389: P 2294133378:2294133416(38) ack 2704546547 win 64860 
 526: 10:06:36.922376 2.2.2.2.3389 > 1.1.1.1.6666: P 2704546547:2704546558(11) ack 2294133416 win 65497 
 527: 10:06:36.922636 1.1.1.1.6666 > 2.2.2.2.3389: P 2294133416:2294133828(412) ack 2704546558 win 64849 
 528: 10:06:36.923978 2.2.2.2.3389 > 1.1.1.1.6666: P 2704546558:2704546895(337) ack 2294133828 win 65085 
 529: 10:06:36.924207 1.1.1.1.6666 > 2.2.2.2.3389: P 2294133828:2294133840(12) ack 2704546895 win 64512 
 530: 10:06:36.924253 1.1.1.1.6666 > 2.2.2.2.3389: P 2294133840:2294133848(8) ack 2704546895 win 64512 
 531: 10:06:36.924955 2.2.2.2.3389 > 1.1.1.1.6666: . ack 2294133848 win 65065

And die again....

I don't understand why the server keep sending RESET packet to the client?

Marcin Latosiewicz · ‎06-14-2010

Morning,

Can you please confrim for me rather the ASA version and where the capture was taken ? (outside or inside of the ASA?)

Please also rememebr that you can extract the captures in pcap so you can open them in wireshark !

from cli (copy /pcap capture ...)

from https Https://Ip.address/capture/CAPTURE_NAME_HERE/pcap

Please note - this is a retranmission.

519: 10:06:34.488256 1.1.1.1.5.5.5.5 > 2.2.2.2.3389: P 457295121:457295657(536) ack 3592134313 win 64860
520: 10:06:36.894423 1.1.1.1.5.5.5.5 > 2.2.2.2.3389: P 457295121:457295657(536) ack 3592134313 win 64860

Followed by reset:

521: 10:06:36.894591 2.2.2.2.3389 > 1.1.1.1.5555: R 3592134313:3592134313(0) ack 457295657 win 64860

To get ot the bottom of things - you'd need to get a capture on both inside and outside interfaces.

Adam David · ‎06-14-2010

Thanks Marcin for the tips on wireshark.

Hardware: ASA5520,
Software Version 8.0(4)32

Yeah, I notice that. The retransmission started at packet 511 to 520 before the server sent the RST packet.

I've captured both inside and outside interface. The only RST packet that I can see is in inside interface.
Here are the commands that I use to capture the network packet.

Access list to filter both source & destination
access-list cap extended permit tcp host 1.1.1.1 host 2.2.2.2
access-list cap extended permit tcp host 2.2.2.2 host 1.1.1.1

Capture both inside & outside interface
capture cap access-list cap interface inside packet-length 54
capture cap-out access-list cap interface outside packet-length 54

View capture
show capture cap-in
show capture cap-out

Let me know if you need more information.

Marcin Latosiewicz · ‎06-14-2010

I understand you don't want to share the pcap based capture for security reasons?

Can you maybe then attach text based capture the full lenght - I'm not sure what I will be able to dig out.

Did you by any chance also try type asp capture?

--------

capture asp type asp all

--------

Will give you information about packet drops on ASA because of security checks ...

larrylewis · ‎06-14-2010

I'm running into the same issue with a recent setup on an ASA 5505 running 8.0(5). I'm seeing the same behavior with a handshake, repeated push from the client and then a reset from client. Trying to initiate another rdp connection shows syns from client but no ack from server. clearing the arp cache helps temporarily but the problem returns after a short time.