Vista corrupts the local routing table when establishing VPN connections when the remote network is in the 10.x.x.x/24 range. This is particularly bad when the Vista machine is the VPN Client, and it is also attached to a 10.x.x.x/24 network. (To be more precise, it affects all VPN connections to any 10.x.x.x networks that aren't using a /8 subnet mask... ie. 255.0.0.0) As a matter of fact, there are three key VPNfailures: 1) DNS Server addresses are used in reverse order from the order that the server side issues them. Also, you cannot get Vista to correct the problem by statically assigning the addresses since it will still use the addresses provided by the server side before using the static addresses. 2) DNS Domain Name suffixes that are provided by the RRAS server are ignored (but you can manually enter them for each connection as long as you do not need to dynamically assign them based on RADIUS logon credentials, as more complex networks do.) 3) The Network ID and subnet mask values are entered into the local routing table based on the IP address issued by the RRAS server instead of using what the RRAS server gives out. For example, if you are establishing a VPN connection to a network that uses a network of 10.1.1.0/24 (aka 10.1.1.0 mask 255.255.255.0), and then to a second VPN connection to a network that uses 10.2.2.0/24, you will find that you lose connectivity to the first network, even though Vista shows that you are still connected. The truth is that you actually are still connected to both networks, but your routing table is now corrupt. In this example, the routing table should have (among other entries) two routes that look like this (likely with different gatweway and interface addresses and metrics): Network Destination Netmask Gateway Interface Metric 10.1.1.0 255.255.255.0 10.1.1.25 10.1.1.27 11 10.2.2.0 255.255.255.0 10.2.2.21 10.2.2.29 11 But in Vista, when you establish the first connection you get this: Network Destination Netmask Gateway Interface Metric 10.0.0.0 255.0.0.0 10.1.1.25 10.1.1.27 11 And, when you establish the second connection, instead of getting a second entry, the first one is overwritten like this: Network Destination Netmask Gateway Interface Metric 10.0.0.0 255.0.0.0 10.2.2.21 10.1.1.29 11 To correct this, even after establishing both VPN connections, you can delete the 10.0.0.0 route entry, and add the two entries that are correct. Once you do that, you will immediately regain access to both remote networks. We can't have thousands of customer service field reps manually editing their routing tables every time they VPN into their corporate office. (Their machines are locked down so that theycan't do it anyway.) Has anybody found a fix for this yet? SP1 did not fix it. Thanks!

Correction: A network of 10.1.1.0/24 actually does work. It's everythingbeyond that that fails.

Weird... Now the connection to the 10.1.1.0/24 network once again corrupts the routing table. Why did it work once for me, and now it won't work? What is going on here?

OK... if the Gateway for the routeshows "On-Link" then it works... when it shows an IP address, it doesn't work. Also, why did it work once, and then go back to corrupting the routing table?

The 10.1.1.0/24 network actually does work... I wasn't waiting for the "identifying" phase to complete itself. But, VPN connections to all other10.x.x.x networks still causes the corruption to the routing table. Please help...

I really want to bang my head against a wall right about now! Now, once again, the connection to the 10.1.1.0/24 network is causing corruption to the routing table. This is happeningwith ALL of my Vista machines! Why is this intermittent? I am connecting to the same VPN (Microsoft RRAS) server every time. I should get the same results every time! What is going on?

The routing table corruption seems to occur when the RRAS server is not a MS Server, or if the MS RRAS Server is not set up to be both a Router and RRAS Server (the RRAS setup wizard configures the server as RRAS onlyby default for VPN servers that aren't used as routers), and is set to allow broadcast name resolution, and also set up to use DHCP, and has the DHCP relay added and configured properly, and there is a WINS server in use, and the DHCP options on the DHCP server includes the WINS Server and Node Type options properly configured. IF... and only if, all of these conditions are met, THEN Vista will not corrupt the routing table. I still can't explain why I am getting intermittent results, but I can now get this to work with other 10.x.x.x/24 networks. Could someone from Microsoft PLEASE give us some clear guideance in terms of what needs to be set up on the RRAS server for this to work consistently. Thanks!

The wording of my last post isn't as clear as I'd like... so, to recap, here is what I found: To improve the odds of not having routing table corruption under Vistawhen connectingvia VPN to a 10.x.x.x/24 network, the server side (whichusers such as field reps that do not work directly for the companywill NOT have any control over) must meet the following conditions: 1) If the RRAS server isa Microsoft RRAS Server, itmust be set up as both a router and RAS server 2) If the RRAS server isa Microsoft RRAS Server, it must be set up to allow broadcast name resolution 3) If the RRAS server isa Microsoft RRAS Server, it must be set up to use DHCP for address assignment 4) The RRAS server must have a DHCP relay agent installed and configured to point to a working DHCP server 5) There must be a working WINS server set up in the environment, and... 6) The DHCP server must give out the address of the working WINS server along with 0x8 as the node type Interestingly, it looks like the RRAS server needs to be a Microsoft RRAS server for this to work. (Can you say antitrust lawsuit? I think Microsoft is already familiar with that concept.) It is important to note that Windows XP, Linux, and the Mac OS do not need all of these conditions to be met in order to work properly. Vista along with its counterpart, Windows Server 2008, are the only two operating systems that require such an extravagant set up to work properly. So, what do all of us do when we VPN into a site that is using exclusively DNS in their environment (ie no WINS)? Vista will corruptits routing table when that environment uses a 10.x.x.x/24 network. What if the network administrator has eliminated the chance of a broadcast storm by disabling the broadcast name resolution capability, and has properly configured DNS to handle all of that? Once again, Vista will corrupt its routing table when that environment uses a 10.x.x.x/24 network. These are real world scenarios that were created by those network administrators who followed Microsoft's recommendations with Windows Server 2000 and 2003 for configuring an efficient network environment. Now Microsoft has released a product that goes back to the old days when Windows 95 was new, and you needed WINS in your environment for everybody to be able to gain access to network resources across routers. Nice job, Microsoft! Sending all of us back to the days of the Dinosaur, so to speak... Is there EVER going to be a fix for this? (Or has Microsoft completely lost their understanding of modern networking?) Please, Microsoft, give us a fix for Vista's and Server 2008's VPN issues!

Has there been a fix posted for this issue yet?

No. Microsoft obviously has no intention of fixing this. They won't even acknowledge the problem. The problem also affects Server 2008, and I have reported that as well to no avail. I have made two phone calls to MS tech support, entered several problem reports, used their beta reporting tool when SP1 was in beta to report this problem, and even spoken with a contact that works at a high level of management in their Redmond, WA office... and NONE of them have followed up with me... and it has been almost 9 months at this point. (At least they have no yet charged my credit card for the phone calls.) By the way, I did discover that the Gateway value in each route entry should say "On Link" when it is working properly, and I can get Vista to eventually get it right by disconnecting and reconnecting over and over again... butour field reps will never go for that. My contact in the Redmond office tells me that they are working on a new, premiumVPN client that we will all have toPAY for. It is supposed to be the ultimate, catch all VPN client... but if they made us pay for it when they won't fix the basic VPN client that ships with Vista, that will be the straw that breaks the camel's back for me and my clients. We are already testing two distros of Linux, together with OpenOffice and a Citrix / VMWare solution, and are finding that we can eliminate Microsoft productsfor at least 80% of our daily business needs. We have over 2000 laptops in the field (that we provide) ALL using VPN, over 500 workstations spread acrossseveral buildings, and one or more servers in each building.We are also working a deal with our application vendor to port our criticalnon-linux apps over to Linux. That would completely eliminate our reliance on Microsoft products all together. And, we are finding that the money we would save by replacing all of our desktop & laptop OS' with Linux will be more than enough to pay for the vendor's modifications to make their application suite work on Linux. The truth of the matter is, if MS sells their new VPN client for $20.00, that will cost uswell over$400,000 to upgrade. We can get our applications ported to Linux for around $35,000. There are an average of 11 field reps assigned to each of the 200 team leads, and each "team" is an outsourced resourse, which means theywould have to purchase their own VPN upgrades, and expense it back to us, with no hope for a price break from Microsoft at that point. So, if Microsoft doesn't fix this rather simple VPN issue by the time our vendor completes their analysis of their code base, and if the vendor is willing to port their code, then we will have all of the incentives that we need to initiate a complete system-wide switch to Linux sometime around Q1 next year. So, although it is only a small drop in the MS ocean, they will lose just about $1,000,000 of revenue from us, every 3 years. We also advise other medium size businesses, so we may be able to get that number up to 3 or 4 million dollars of lost revenue... but I still don't think that will be enough to get Microsoft to start listening to us. I do hope that Microsoft starts to listen to us, and fix Vista's and Server 2008's networking issues, for all of our sakes. If not... say bye-bye toMicrosoft products from all of our equipment, at least. Take care!

There may be a workaround that I found by trying a couple of settings ... at least it worked well for me. ;) What I noticed for the new established PPP connection for my office VPN,was thatthe gateway was set to 0.0.0.0. Just uncheck "Use default gateway on remote network" in the Advanced TCP/IP Settings of your VPN's TCP/IP v4/6 properties (it's in the Networking tab) and it may just work. Cheers, Lucian PS. I got vista ultimate and it goes out through a wireless rounter linked to my ISP's adsl router.

I haven't looked at this thread in a long time... Once again, Microsoft gave its customers the shaft. This problem was resolved in Windows 7 by allowing us to disable automatic Class-based route additions in our VPN configurations. The same fix would work perfectly if it was implemented into Windows Vista but, of course, Microsoft has yet to even acknowledge that the issue exists in Vista, even though there is a very visible setting in Windows 7 that addresses the issue. As for me and the people I work with, we have all switched to SLED 11 and OpenOffice.org, and I typically run Windows 7 Professional in a Virtual Machine running under Vmware Workstation 7. I still run Windows 7 on my gaming machine at home, but Linux on all of our business machines. If Microsoft had simply implemented the fix for this issue into Windows Vista and not just Windows 7, they probably wouldn't have lost so many customers. Oh well... We have partnered with several other companies to implement various remote access technologies into production. There are several thousand people who are now looking forward to the next couple of years of being leaders in their respective industries and, later this week, they will decide whether to use Microsoft products or Open Source. There are thousands upon thousands of units of sales at stake, and all of them would have been sales to Microsoft... but these customers are all sick and tired of Microsoft's lack of regard for their Corporate customers. We will see at the end of this week who they decide to go with... This should prove to be interesting.