intermittent connectivty

mickyq — Wed, 13 Mar 2019 01:08:28 GMT

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

Hello, Lets start from

Julio Carvajal — Mon, 06 Jul 2015 20:28:03 GMT

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

Hi Juliothanks for your reply

mickyq — Tue, 07 Jul 2015 10:46:22 GMT

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

topic intermittent connectivty in Network Security

intermittent connectivty

Hello, Lets start from

Hi Juliothanks for your reply