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
_______________________________________________
vpn-help mailing list
[email protected]
https://lists.shrew.net/mailman/listinfo/vpn-help
