Hello, I have a Windows 7 guest VM installed in Parallels 5.0.9308 on Snow Leopard. I have always regularly used Cisco VPN Client (v4.9.01.0180) in Mac OS and then used the Windows VM to access various VPN-based resources (e.g. Outlook, web GUI's etc). In Parallels 4 and the initial 5.0 release (build 9220?) this "just worked" with shared networking and the Windows VM nic set to DHCP. When logging into the VPN, the client updates the Mac OS DNS settings so that my DNS servers become the Internal DNS servers over the VPN link. Then I can access any internal resources as if I was in the office, from either Mac OS or the Windows VM. I have updated to 5.0.9308 and it looks like this has somehow broken DNS-over-VPN. I login to the VPN as normal in Mac OS, but now the Windows VM doesn't seem to like the updated DNS settings in Mac OS. For example, if I login to the VPN and do an nslookup on exchange.domain.com on Mac OS terminal, I get the internal 10.x.x.x IP from my office VPN as I would expect. In Windows I would expect the same, but now I'm getting the external IP as if I was not logged into the VPN. Interestingly, if I manually try connect to the internal IPs, or configure the Windows VM NIC with the Internal DNS server IP, it works OK. This means the VPN link itself is accessible from the Windows VM, but for some reason the DNS requests are being routed incorrectly somehow to the old Mac OS DNS servers (before the VPN was enabled). Unfortunately I jump on and off the VPN all day, so having to manually change this all the time isn't suitable. I've tried releasing, renewing, enabling/disabling the Windows VM NIC, I've tried using Bridged networking, I've tried logging into the VPN before I boot the Windows VM guest. Unfortunately none of these make any difference. I don't really want to downgrade back to 5.0.9220 because 9308 has improved the performance of the VM quite a bit. Any ideas? Thank you! Alasdair
Could you please enable Verbose Logging via menu "Parallels Desktop -> Preferences -> General -> Use detailed log messages", then connect to VPN. Then try to ping from Windows some VPNd server by its name (or just access it). Then click menu of Parallels Desktop "Help" -> "Report a Problem" and post a problem report (the description is not necessary) and post here its id. After that disable the Verbose Logging.
Could you please try embedded in Snow Leopard VPN client? It should work with it. Another way is to make the VPN's dns-server be a primary DNS server at Windows-side: open LocalAreaConnection preferences -> TCP/IP v4 -> and make this dns-server be Primary DNS Server. Secondary should be 10.211.55.1 - Parallels Shared Networking DNS server. It should work even if VPN connection is not established This behaviour is unexpected for us, so at the moment I can't say much
Having same problem I'm having exactly the same problem - can you elaborate on "Could you please try embedded in Snow Leopard VPN client?" How do I do that exactly? --Laureen
Here is a sample of configuration: http://www.stanford.edu/group/macosxsig/blog/2009/08/using_cisco_vpn_with_snow_leop.html We will work on resolving the issue
I followed the instructions in the link provided but at this step "On the Mac, chose VPN as the interface. Choose Cisco IPSec as the VPN type" there was no Cicso IPSec choice. I also tried previous suggestion of changing the primary DNS to the one my VPN used and that didnt' work either. Please advise - I am losing productivity at work and this is right on the heels of bragging how well this configuration worked for those going from windows to mac. --Laureen
Would you mind about WebEx session to investigate the problem and tune the workaround on your machine? I've created a support ticket 842491
Just an update on this, the dual-DNS-servers in the Windows guest VM did work around this problem for me. It's not exactly clean, and I hope this issue is resolved cleanly in the next Parallels Update. However at least I have a workaround in place now.
I'm running in exact same issue. I'm using build 5.0.9310 with Checkpoint VPN for SN (EA). Looking forward to see this fixed as it also used to work before in older releases.
