Regression: VPN disconnects on receiving large packets

[Davíð Steinn Geirsson]

Hi Nikos,

Looks like you were right, with the patch applied the connection stays
up. Thanks a lot!

The remote gateway is from cisco and from the login banner I'd guess
it's an ASA box, but I'm not sure which version it is that behaves this way.

Best regards,
Davíð

On 06/24/2016 07:57 AM, Nikos Mavrogiannopoulos wrote:
> It could be that in CSTP mode the server doesn't respect the MTU. Does
> the attached patch address the issue for you?
> 
> On Wed, Jun 22, 2016 at 5:59 PM, Davíð Steinn Geirsson <dsg at sensa.is> wrote:
>> Hi all,
>>
>> Recently a coworker had some problems connecting to the company VPN
>> using openconnect. The same VPN worked fine for me. The only seeming
>> difference was the version of openconnect, as his was a newer version
>> from fedora 23 instead of the older one from debian stable I was using.
>>
>> On the faulty versions, the VPN connects fine and works for a bit, but
>> then when the server sends a lot of data in one go (such as the result
>> of a 'ls' in a large directory over ssh), the VPN disconnects. Forcing a
>> smaller MTU with --mtu=1280 --base-mtu=1280 made no difference.
>>
>> The last messages from the failing connection are as follows:
>> Connected tun0 as 10.26.103.76, using SSL
>> Unexpected packet length. SSL_read returned 1414 but packet is
>> 53 54 46 01 05 8c 00 00
>> Unknown packet b2 c4 ba fa 75 bb 20 6d
>> Send BYE packet: Unknown packet received
>> Unknown error; exiting.
>>
>> I did a 'git bisect' and this regression seems to have been added in
>> commit f26b11e7616bf735e8e34482433b198db862302d. Specifically, this
>> check for the magic header is failing:
>> +               if (vpninfo->cstp_pkt->hdr[0] != 'S' ||
>> vpninfo->cstp_pkt->hdr[1] != 'T' ||
>> +                   vpninfo->cstp_pkt->hdr[2] != 'F' ||
>> vpninfo->cstp_pkt->hdr[3] != 1 ||
>> +                   vpninfo->cstp_pkt->hdr[7])
>>                         goto unknown_pkt;
>>
>> The connection works fine with the commit directly preceding this one,
>> 50b085039216e45e5d510d4519347eea7b7f7679. It has the same check
>> (perfomed on the large buf instead of vpninfo->cstp_pkt->hdr) which
>> succeeds, yet both get their data from similar calls to cstp_read().
>>
>> I'm a bit stuck here, does anyone have any ideas why cstp_read() would
>> be returning wrong data here?
>>
>> Best regards,
>> Davíð
>>
>>
>> _______________________________________________
>> openconnect-devel mailing list
>> openconnect-devel at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/openconnect-devel
>>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/openconnect-devel/attachments/20160624/bd99cbdd/attachment.sig>