[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