Unstable RDP sessions

Unanswered Question
May 31st, 2010
User Badges:

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

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
Adam David Sun, 06/13/2010 - 22:34
User Badges:

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 Mon, 06/14/2010 - 02:24
User Badges:
  • Cisco Employee,

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 Mon, 06/14/2010 - 03:16
User Badges:

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 Mon, 06/14/2010 - 03:42
User Badges:
  • Cisco Employee,

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 Mon, 06/14/2010 - 14:02
User Badges:

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.

Actions

This Discussion