[Vpn-help] Iked.exe dies
Matthew Grooms
mgrooms at shrew.net
Wed Oct 24 11:30:45 CDT 2007
Peter Eisch wrote:
> On 10/24/07 12:10 AM, "Matthew Grooms" <mgrooms at shrew.net> wrote:
>
>> Thanks again for the bug report. I'm glad you caught this as I was just
>> writing the 2.0.2 release announcement. This build should set you
>> straight :)
>>
>> http://www.shrew.net/vpn/download.php?name=vpn-client&vers=2.0.2-release-x86
>>
>
> This is good! It popped right up and worked as you'd expect.
>
Peter,
Could you please clarify. Is the problem you describe below something I
need to look at in 2.0.2 or are you recounting problems with 2.0.0? If
it is still a problem, there is an undocumented Win32 API call I can try
which flushes the DNS resolver cache. Please let me know.
>
> Also, we consistently get a behavior where the VPN needs to be up for 9-11
> minutes before it starts "working." The issue isn't in transport -- that is
> working properly. The problem is that windows seems to cache public DNS
> responses for about that long and it doesn't retry over the VPN until that
> cache expires.
>
> For example the user has Outlook running with no/vpn. They then connect the
> VPN and general Internet browsing mostly works (caching behavior doesn't
> seem to happen) but Outlook literally sits at "Trying to connect..." [to
> exchange] through this duration. Even if it's quit before the VPN is
> launched. This leads me to think that there might be some sort of WINS
> cache or something that needs to get poked when connected and disconnected.
> What too is odd is that from a cmd prompt the public addresses are used if
> you try to ping these domain systems. Again, non-domain systems tend to
> respond properly.
>
> On OS X the trick is to signal USR2 to lookupd (well, it was through 10.3,
> I'm just new to 10.4) to drop its cache. Is there something similar that
> can be done on windows?
>
> Thanks Matt!
>
Thanks,
-Matthew
More information about the vpn-help
mailing list