<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 6.5.7652.24">
<TITLE>AW: [Vpn-help] DNS suffix search list</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->
<P><FONT SIZE=2>Hi Matthew,<BR>
<BR>
Thank you for your awnser.<BR>
<BR>
We have the same issue (using Racoon on Linux as VPN gateway), i investigated it with Wireshark. What I found out that, after the VPN is connected, the request for DNS went to the local DNS Server not the one specifed for the VPN. The local DNS Server denied the request (host unknown) and you get no name resoulution.<BR>
After you stop the dns cache and restarted it or using ipconfig /renew the DNS request went to the right DNS Server and the name resolve is working.<BR>
What me confsued is that, after you are connected and no DNS is working you get the right DNS Server with the nslookup Tool under Windows, the request with nslookup are working but no resolution with tools like ping.<BR>
I tried the 2.1 A5 without luck and using the DNSCache workaround... If you need further help I can offering you my help.<BR>
<BR>
Jascha<BR>
<BR>
-----Ursprüngliche Nachricht-----<BR>
Von: mgrooms [<A HREF="mailto:mgrooms@shrew.net">mailto:mgrooms@shrew.net</A>]<BR>
Gesendet: So 1/13/2008 2:14<BR>
An: Jascha Petersen<BR>
Cc: vpn-help@lists.shrew.net<BR>
Betreff: Re: [Vpn-help] DNS suffix search list<BR>
<BR>
<BR>
On Sun, 13 Jan 2008 00:32:21 +0100, "Jascha Petersen"<BR>
<jascha.petersen@circle-unlimited.de> wrote:<BR>
> Hi,<BR>
><BR>
> What I found out that you can do perhaps a "ipconfig /renew" what also<BR>
> should work<BR>
><BR>
> Will this "bug" be fixed in one in the 2.1 release?<BR>
><BR>
<BR>
I would love to fix this problem for the 2.1.0 release. Up till now I had<BR>
only head the problem reported by two sources. From the response this<BR>
thread is getting, I will now assume that this problem is more wide spread.<BR>
Unfortunately, I'm not exactly sure what really causes the issue.<BR>
<BR>
For example, stopping and starting the Micorsoft dnscache service after the<BR>
connect connects seems to help but I'm not sure why. At first I thought it<BR>
was due to negative DNS entries being cached by the dnscache service but<BR>
these are now flushed by the client at connect time and disconnect time. To<BR>
test this independently, you can run an "ipconfig /displaydns" before and<BR>
after the client connects. You will notice that all DNS entries are purged<BR>
from the dnscache table. We also tried setting the TTL for negative DNS<BR>
entries to 0, which disables this feature in the dnscache service, but that<BR>
didn't seem to help the problem either.<BR>
<BR>
Peter and Brian have been very helpful in trying to narrow down the cause<BR>
of this problem but we have yet to find a real answer. Tai-hwa Liang, also<BR>
noticed this issue and was very helpful in testing the 2.1.0 alpha 5<BR>
release. In contrast, he reported the problem had been resolved for him on<BR>
all the workstations he tested. This leads me to believe there may have<BR>
been two problems and that only one of them was solved when I rewrote the<BR>
adapter configuration and DNS Transparent Proxy Daemon for alpha 5.<BR>
<BR>
So ... How many people are seeing this issue with the latest 2.1.0 alpha 5<BR>
release? I am open to any suggestions people may have about the nature of<BR>
the problem or how to potentially correct it. Has anyone tried stopping the<BR>
Shrew Soft DNS Transparent Proxy service before connecting to see if this<BR>
has an impact? Does stopping and starting the dnscache service after<BR>
connecting to the gateway solve this problem for everyone?<BR>
<BR>
Thanks,<BR>
<BR>
-Matthew<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
</FONT>
</P>
</BODY>
</HTML>