[vpn-help] Fragmented traffic with 2.2.0-rc-2

[Kevin VPN]

On 02/22/2013 08:49 AM, Alexis La Goutte wrote:
> Hi Marcel,
>
> With 2.2-rc2, there is new hash algo supported... (See
> https://lists.shrew.net/pipermail/vpn-help/2012-December/014061.html )
>
> Regards,
>
> On Thu, Feb 21, 2013 at 3:49 PM, Zweerde, Marcel van de <
> mvandezweerde at alescon.nl> wrote:
>
>> I’m having some problems with fragmented traffic (and disconnects)****
>>
>> Netscreen 320M 6.3.0r9.0****
>> Block Fragment Traffic Enabled in screen settings for the Untrust interface
>>
>>           Win7 client (etc.)****
>>           Client 2.2.0-rc-2****
>>
>> ** **
>>
>> Problem:****
>>
>> The setup is working correctly (except for some random?!? disconnects) if
>> i disable “Block Fragment Traffic” but it seems slow. ****
>>
>> When “Block Fragment Traffic” is Enabled on the Netscreen the tunnel
>> connects but i get fragmented UDP traffic alarms on the Netscreen and there
>> is no traffic through the tunnel.****
>>
>> ** **
>>
>> To remedy the situation i tried to lower the MTU setting to 800 as a test
>> in the client but that doesn’t seem to work.****
>>
>> The MTU value for the virtual adapter changes in the registry but the log
>> says otherwise?!?****
>>
>> ** **
>>
>> Interesting log entry’s:****
>>
>> A*p*apter ROOT\VNET\0000 MTU is 1500****
>> Send NAT-T:IKE packet XXXX:4500 -> XXXXX:4500 ( 1548 bytes )****
>> Fragmented packet to 1514 bytes ( MTU 1500 bytes )****
>> Fragmented packet to 82 bytes ( MTU 1500 bytes )****
>>
>> ** **
>>
>> How can i resolve this? (hopefully without changing anything to the pc
>> config itself)****
>>
>> (Maby the disconnects are related to the fragmenting?, the client says the
>> Netscreen ended the connection but the Netscreen doesn’t log anything.)***
>> *
>>

Hi Marcel,

I'm wondering if maybe the latest version of Shrew doesn't respect the 
MTU/fragment settings - or we don't understand properly how they're 
supposed to work according to the IPsec RFCs.

I was trying to troubleshoot a problem that I thought was MTU-related as 
well.  I couldn't reproduce it myself because I think it was a 
firewall/router in the client's path dropping the packets (rather than 
my firewall). I was giving the client instructions, including changing 
the Local Host Adapter MTU (on the General tab) and changing the IKE 
Fragmentation enable/disable/force and Maximum packet size on the Client 
tab.  Despite setting them both to much smaller sizes, the user still 
had the same problem.

If I change the Local Host Adapter MTU on my machine (say to 1000), I 
still see a

apapter ROOT\VNET\0000 MTU is 1500

in the VPN Trace log.  Interestingly, that 1500 also shows up when using 
a connection that uses the default MTU of 1380.

(I also note a typo in the log output - 'apapter' instead of 'adapter'.)