Cisco Bug ID CSCea93394.. Says its resolved, but its there is no "Fixed in" version number, so I am guessing that means next release...
Release Notes
This is specific to windows version of 4.0 VPN Client. This should not
occur on non-windows platforms or earlier versions of the VPN Client.
When a tunnel is established, the head-end could send a DNS domain to
be used by the client by mode cfg. The VPN Client makes the changes to
the system to use the DNS suffix pushed by the head-end. This is working
fine without any problems. But when the tunnel is disconnected, we don't
undo the DNS suffix change that was made at tunnel connection time.
Example of this problem:
1. Lets say fully qualified hostname is mymachine.mynet.com. Thus the
DNS suffix is mynet.com
2. Using command shell, ping some computer e.g. "ping someComputer"
3. If you use sniffer, the request would go out as someComputer.mynet.com
i.e. the OS would append the DNS suffix to the hostname.
4. Then tunnel is established, and "cisco.com" is pushed by the head-end.
5. Execute the ping command in step 2, and the request that goes out on
wire would be someComputer.cisco.com. This is the expected behavior
6. Disconnect the tunnel
7. Execute the ping command in step 2. The request that goes on the wire
would be someComputer.cisco.com. This is not the expected behavior. It should
be someComputer.mynet.com.
How to verify if you are running into this problem?
If you go to Network Connections > Adapter Properties > Internet Protocol
(TCP/IP) > Properties > Advanced button > DNS tab. This property page
gives more information about the DNS suffix used. You can view the properties
before tunnel establishment, and after the tunnel establishment, and then
at disconnect to see the bug.
You can also see the tunnel suffix used by using the "ipconfig -all" command.
