[PATCH 3/3] Drop packets that are too large without dropping connection

[Nikolay Martynov]

2017-05-11 12:20 GMT-04:00 Daniel Lenski <dlenski at gmail.com>:
> On Thu, May 11, 2017 at 9:09 AM, Nikolay Martynov <mar.kolya at gmail.com> wrote:
>> 2017-05-11 12:00 GMT-04:00 Daniel Lenski <dlenski at gmail.com>:
>>> On Wed, May 10, 2017 at 8:03 PM, Nikolay Martynov <mar.kolya at gmail.com> wrote:
>>>> This improves connection stability.
>>>
>>> How so? What is the downside to accepting an unexpectedly large packet
>>> which nevertheless managed to make it across the VPN tunnel?
>>
>>   This patch goes from current state which is 'drop connection if
>> there is packet larger than MTU in the tunnel' to the state 'drop
>> packet if it is larger than MTU, but keep connection' - this improves
>> connection stability.
>>
>> Somehow with tunnels that I've gotten with my
>> employer I often get packets in that are larger than MTU (and it looks
>> like they have DF flag set). I do not know exact cause of it - and I
>> do not have access to VPN equipment, unfortunately. But this patch
>> improves connection stability with this setup. Higher stacks figure
>> out MTU value and continue normally after first dropped packet.
>> 'Official' client (pulse) seems to set up MTU to 1400 on interfaces it
>> creates - same as does openconnect.
>>
>>   Obviously we can just inject large packets higher up the stack, but
>> I'm not exactly sure what sort of side effects would happen if we do
>> that. So I sort of tried to play safe here.
>
> Interesting, thanks for explaining. I have access to a couple Juniper
> VPNs as well (older version, not Pulse), but I haven't observed this
> behavior from them.
>
>>   I guess this code can be improved for cases when MTU is not
>> known/not known exactly - but unfortunately I do not have equipment to
>> test such changes. Change I've sent improves connection stability with
>> pulse vpn server.
>>
>>   Please let me know if you would like me to improve that patch.
>
> Yeah, that's really my only concern here. It might be safer simply to
> pass through packets which are larger than the negotiated or estimated
> MTU, as long as they're otherwise well-formed. I am not sure, however,
> if this could impede MTU detection by higher levels of the protocol
> stack.
>
> What happens if you keep only this part of your patch but don't drop
> the packets?
  I'd have to test this and get back to you.
  But I guess I will have similar question for you here: in your
setups and your code base when MTU is not known - how is it currently
handled?
  I kind of feel that in situation when MTU is not known better/safer
approach is to just setup interface with MTU equal to largest possible
MTU - to some definition of 'largest'.
  But I'm by no means an expert here, so I'm just asking :).

-- 
Martynov Nikolay.
Email: mar.kolya at gmail.com