CSCvu08013 - DTLS v1.2 and AES-GCM cipher when used drops a particular size packet frequently.

[gkcweber1]

It took us some time to link all kind of bug reports to this issue - specific revisions in a SVN cannot get pushed, some websites cannot be opened (single posts on a discussion board, only specific wiki pages, ...), but later they can, and so on and on and on. For us it were packets with a ip.len==927, for example they can be created with (IP:20+ICMP:8+DATA:899==927)

(Windows) ping -l899 $ip
(Linux) ping -s899 $ip

As an icmp echo response is of same size as the request, it doesn't matter if you initiate the ping on the inside or outside. As for us the packet size was a different than stated in the bug, you can sweep with

for PACKETSIZE in $(seq 0 1492); do ping -c1 -n $IP -s $PACKETSIZE; done

(it will start fragmenting somewhere).

[Joe Budz]

I had this issues as well. My symptoms were very strange...

Symptom 1) Some users, sometimes while connected to the VPN could not send email.

Symptom 2) Jabber would not ring for my work from home users.

Symptom 3) As described above, pings of 899 bytes to any server accessible over the VPN would fail. (ping -l 899 10.X.X.X)

I upgraded to 9.14(1)15 and all issues have disappeared. What upsets me is that Cisco has not changed the recommended release. As it stands the recommended release is 9.12.3 which contains the bug. Other than the work around mentioned for this bug, another fix is to disable DTLS altogether.

Group-policy <Group-policy-name> attributes

webvpn

anyconnect ssl dtls none

However that slowed the throughput of my end users down.

Hope this helps someone,

Joe

[alina.savin]

were you seeing the dropped packets in the asp-drop packet capture?

[Joe Budz]

I did not do a packet capture

[rfarrington]

We ran into this exact same issue and the dropped packets were not being logged in the asp-drop capture.