[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