cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
567
Views
0
Helpful
2
Replies

intermittent connectivty

mickyq
Level 4
Level 4

I have a problem with a site behind an ASA. It is an intermittent fault. I have Wyse terminals which provide a virtual desktop. The problem I see is the desktop sometimes connects and other times it doesnt.
A capture of the traffic between a terminal and the back end when it fails suggests the asa is dropping packets on the inside interface. see cap below.
The terminals are in a dmz (10.71.63.0/24) and the virtual environment is on the inside (172.24.16.0/24).
Connectivty from terminals on the inside to the virtual envronment are fine as they dont traverse a firewall.

ASA1/pri/act(config)# show cap dmz
3 packets captured
   1: 15:48:43.758459 10.71.63.32.60400 > 172.24.16.10.21: S 3383991654:3383991654(0) win 65535 <mss 1460,nop,nop,sackOK>
   2: 15:48:43.758658 172.24.16.10.21 > 10.71.63.32.60400: S 1253414733:1253414733(0) ack 3383991655 win 4380 <mss 1380>
   3: 15:48:43.758948 10.71.63.32.60400 > 172.24.16.10.21: . ack 1253414734 win 65535
3 packets shown

ASA1/pri/act(config)# show cap ins
6 packets captured
   1: 15:48:43.758536 10.71.63.32.60400 > 172.24.16.10.21: S 3680533421:3680533421(0) win 65535 <mss 1380,nop,nop,nop,nop>
   2: 15:48:43.758643 172.24.16.10.21 > 10.71.63.32.60400: S 645341401:645341401(0) ack 3680533422 win 4380 <mss 1460>
   3: 15:48:43.758963 10.71.63.32.60400 > 172.24.16.10.21: . ack 645341402 win 65535
   4: 15:48:43.759909 172.24.16.10.21 > 10.71.63.32.60400: S 956706609:956706609(0) ack 3680533422 win 8192 <mss 1460>
   5: 15:48:46.770345 172.24.16.10.21 > 10.71.63.32.60400: S 956706609:956706609(0) ack 3680533422 win 8192 <mss 1460>
   6: 15:48:52.776342 172.24.16.10.21 > 10.71.63.32.60400: S 956706609:956706609(0) ack 3680533422 win 8192 <mss 1460>
6 packets shown

From this capture I can see traffic from the source (10.71.63.32) leaving the dmz. The destination replies (172.24.16.10) in what looks like a three way handshake. After this initial communication, 172.24.16.10 sends a further three syns that can be seen on the inside but not on the dmz interface suggesting the asa is dropping the packets.

Output from, cap drops type asp-drop all doesnt show why the packets are dropped. I didnt save this cap.

As I say the same teminal can connect when rebooted, its very hit and miss.

The cap above is the full cap of a failed connection. A capture when its working obviously has a lot more packets. below is the start of a capture of a successfull connection.

ASA1/pri/act(config)# show cap dmz
   1: 15:52:14.843446 10.71.63.32.63832 > 172.24.16.10.21: S 3175021250:3175021250(0) win 65535 <mss 1460,nop,nop,sackOK>
   2: 15:52:14.844560 172.24.16.10.21 > 10.71.63.32.63832: S 1053876289:1053876289(0) ack 3175021251 win 8192 <mss 1380>
   3: 15:52:14.844896 10.71.63.32.63832 > 172.24.16.10.21: . ack 1053876290 win 65535
   4: 15:52:14.845674 172.24.16.10.21 > 10.71.63.32.63832: P 1053876290:1053876317(27) ack 3175021251 win 64860
   5: 15:52:14.846162 10.71.63.32.63832 > 172.24.16.10.21: P 3175021251:3175021267(16) ack 1053876317 win 65535
   6: 15:52:14.846605 172.24.16.10.21 > 10.71.63.32.63832: P 1053876317:1053876389(72) ack 3175021267 win 64844
   7: 15:52:14.847078 10.71.63.32.63832 > 172.24.16.10.21: P 3175021267:3175021289(22) ack 1053876389 win 65535
   8: 15:52:14.849321 172.24.16.10.21 > 10.71.63.32.63832: P 1053876389:1053876410(21) ack 3175021289 win 64822
   9: 15:52:14.849718 10.71.63.32.63832 > 172.24.16.10.21: P 3175021289:3175021297(8) ack 1053876410 win 65535
  10: 15:52:14.850114 172.24.16.10.21 > 10.71.63.32.63832: P 1053876410:1053876430(20) ack 3175021297 win 64814
  11: 15:52:14.850450 10.71.63.32.63832 > 172.24.16.10.21: P 3175021297:3175021331(34) ack 1053876430 win 65535
  12: 15:52:14.854661 172.24.16.10.21 > 10.71.63.32.63832: P 1053876430:1053876440(10) ack 3175021331 win 64780
  13: 15:52:14.855043 10.71.63.32.63832 > 172.24.16.10.21: P 3175021331:3175021365(34) ack 1053876440 win 65535
  14: 15:52:14.855851 172.24.16.10.21 > 10.71.63.32.63832: P 1053876440:1053876460(20) ack 3175021365 win 64746
  15: 15:52:14.856172 10.71.63.32.63832 > 172.24.16.10.21: P 3175021365:3175021371(6) ack 1053876460 win 65535
  16: 15:52:14.856950 172.24.16.10.21 > 10.71.63.32.63832: P 1053876460:1053876508(48) ack 3175021371 win 64740
  17: 15:52:14.857484 10.71.63.32.53219 > 172.24.16.10.1807: S 2150162784:2150162784(0) win 65535 <mss 1460,nop,nop,sackOK>
  18: 15:52:14.858369 172.24.16.10.1807 > 10.71.63.32.53219: S 2033433676:2033433676(0) ack 2150162785 win 8192 <mss 1380,nop,nop,sackOK>
  19: 15:52:14.858659 10.71.63.32.53219 > 172.24.16.10.1807: . ack 2033433677 win 65535

(NB. just realised the first 6 lines below are from another device but the rest is valid. I forgot to update the cap acl)


ASA1/pri/act(config)# show cap ins
   1: 15:51:39.135567 10.71.63.14.50019 > 172.24.16.10.21: S 2331540030:2331540030(0) win 65535 <mss 1380,nop,nop,nop,nop>
   2: 15:51:39.135796 172.24.16.10.21 > 10.71.63.14.50019: S 3344387758:3344387758(0) ack 2331540031 win 4380 <mss 1460>
   3: 15:51:39.136116 10.71.63.14.50019 > 172.24.16.10.21: . ack 3344387759 win 65535
   4: 15:51:39.137062 172.24.16.10.21 > 10.71.63.14.50019: S 282627678:282627678(0) ack 2331540031 win 8192 <mss 1460>
   5: 15:51:42.146675 172.24.16.10.21 > 10.71.63.14.50019: S 282627678:282627678(0) ack 2331540031 win 8192 <mss 1460>
   6: 15:51:48.152610 172.24.16.10.21 > 10.71.63.14.50019: S 282627678:282627678(0) ack 2331540031 win 8192 <mss 1460>
   7: 15:52:14.843523 10.71.63.32.63832 > 172.24.16.10.21: S 66228745:66228745(0) win 65535 <mss 1380,nop,nop,nop,nop>
   8: 15:52:14.844545 172.24.16.10.21 > 10.71.63.32.63832: S 3830949069:3830949069(0) ack 66228746 win 8192 <mss 1460>
   9: 15:52:14.844896 10.71.63.32.63832 > 172.24.16.10.21: . ack 3830949070 win 65535
  10: 15:52:14.845659 172.24.16.10.21 > 10.71.63.32.63832: P 3830949070:3830949097(27) ack 66228746 win 64860
  11: 15:52:14.846178 10.71.63.32.63832 > 172.24.16.10.21: P 66228746:66228762(16) ack 3830949097 win 65535
  12: 15:52:14.846605 172.24.16.10.21 > 10.71.63.32.63832: P 3830949097:3830949169(72) ack 66228762 win 64844
  13: 15:52:14.847093 10.71.63.32.63832 > 172.24.16.10.21: P 66228762:66228784(22) ack 3830949169 win 65535
  14: 15:52:14.849306 172.24.16.10.21 > 10.71.63.32.63832: P 3830949169:3830949190(21) ack 66228784 win 64822
  15: 15:52:14.849718 10.71.63.32.63832 > 172.24.16.10.21: P 66228784:66228792(8) ack 3830949190 win 65535
  16: 15:52:14.850099 172.24.16.10.21 > 10.71.63.32.63832: P 3830949190:3830949210(20) ack 66228792 win 64814
  17: 15:52:14.850450 10.71.63.32.63832 > 172.24.16.10.21: P 66228792:66228826(34) ack 3830949210 win 65535
  18: 15:52:14.854646 172.24.16.10.21 > 10.71.63.32.63832: P 3830949210:3830949220(10) ack 66228826 win 64780
  19: 15:52:14.855043 10.71.63.32.63832 > 172.24.16.10.21: P 66228826:66228860(34) ack 3830949220 win 65535
  20: 15:52:14.855836 172.24.16.10.21 > 10.71.63.32.63832: P 3830949220:3830949240(20) ack 66228860 win 64746
  21: 15:52:14.856187 10.71.63.32.63832 > 172.24.16.10.21: P 66228860:66228866(6) ack 3830949240 win 65535
  22: 15:52:14.856919 172.24.16.10.21 > 10.71.63.32.63832: P 3830949240:3830949288(48) ack 66228866 win 64740
  23: 15:52:14.857530 10.71.63.32.53219 > 172.24.16.10.1807: S 2922463811:2922463811(0) win 65535 <mss 1380,nop,nop,sackOK>
  24: 15:52:14.858369 172.24.16.10.1807 > 10.71.63.32.53219: S 1066082668:1066082668(0) ack 2922463812 win 8192 <mss 1460,nop,nop,sackOK>
  25: 15:52:14.858674 10.71.63.32.53219 > 172.24.16.10.1807: . ack 1066082669 win 65535

If anyone has any ideas I would appreciate any help with this one.

Thanks

2 Replies 2

Julio Carvajal
VIP Alumni
VIP Alumni

Hello,

 

Lets start from scratch!

 

Who is the source of the traffic and where does it sit?

Who is the destination of the traffic and where does it sit?

 

Can you show us the respective ACL and NAT rules for this traffic to traverse the ASA?

 

What do you mean by Connectivty from terminals on the inside to the virtual envronment are fine as they dont traverse a firewall

 

Regards

Julio Carvajal
Senior Network Security and Core Specialist
CCIE #42930, 2xCCNP, JNCIP-SEC

Hi Julio

thanks for your reply. I actually found what the issue was yesterday and fixed it by upgrading the ios.

Here is a link to what was a very similar issue to mine. They obviously explained it better 🙂

https://supportforums.cisco.com/discussion/10757901/asa-drops-retransmission-packets-because-alteon-randomization

Review Cisco Networking for a $25 gift card