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

Matthew Grooms mgrooms at shrew.net
Wed Apr 3 00:17:37 CDT 2013


On 3/21/2013 8:50 PM, Kevin VPN wrote:
>
> 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'.)
>

I looked into this. My thought is that I may have broken setting MTUs 
with the latest RC since I juggled around some adapter configuration 
functions. But I just tested things and they look fine. I also stepped 
through the code that obtains the adapter MTU, and it is definitely 
returning 1500, but that value is apparently incorrect. If I run the 
following from the command line ...

"netsh interface ipv4 show subinterfaces"

... it clearly shows the adapter MTU set to 1380 which is the correct 
value according to the registry entry. Apparently, the API function I'm 
using is broken ...

http://stackoverflow.com/questions/2790541/mtu-mismatch-between-getifentry-and-netsh

I'll try to get this resolved in the next day or two.

-Matthew



More information about the vpn-help mailing list