VPN Client Incorrect Netmask (Vista -> Win2K3)

From my development machine running Windows Vista, I often have to
establish multiple VPN connections to Windows 2003 servers on
different networks (i.e. for maintenance at different hosting
environments).

In each case, the remote subnet that I connect to is a 10.x.y.z/24.
For example, the remote subnet might be 10.88.0.0/24 and I would
access IP addresses in the range 10.88.0.1 through 10.88.0.255. When
a particular VPN connection is established, my local routing table (as
the client) is modified with the following entries:

Network Destination Netmask Gateway Interface
Metric
10.0.0.0 255.0.0.0 10.88.0.80
10.88.0.81 21
10.88.0.81 255.255.255.255 On-link
10.88.0.81 276

This works just fine for one connection. Notice, however, that the
routing table entry states that the remote subnet is 10.0.0.0/8.
According to this post:

http://groups.google.com/group/micro...531033487b698f

"Since the subnet mask depends only on the received IP it uses the old
class rules. So if it gets a 192.168.x.y address it uses a 24-bit
mask. If it gets a 10.x.y.z address it uses an 8-bit mask."

The problem arises when I establish an additional VPN connection to
any 10.x.y.z/24 subnet, for example, 10.88.1.0/24. The only network
that is accessible is the first. I need a way to convey to Windows
that in fact the remote network is not a /8, it is a /24, so that both
networks are accessible over VPN concurrently.

For each connection, the "use default gateway" option is unchecked.
It doesn't appear that there are any other significant connection
options for the routing of a VPN connection.

Does anyone know of a way to make this work?

No there isn't really any way around that problem. The dialup client was
designed to allow a remote user to connect to a LAN and access the resources
there. It was not designed to allow simultaneous access to many different
sites. You have very limited options. It really boils down to having a
default route to the remote server or a subnet route. See KB 254231.

"Mike Petito" <(E-Mail Removed)> wrote in message
news:0775aa5a-07e7-4510-ad90-(E-Mail Removed)...
> From my development machine running Windows Vista, I often have to
> establish multiple VPN connections to Windows 2003 servers on
> different networks (i.e. for maintenance at different hosting
> environments).
>
> In each case, the remote subnet that I connect to is a 10.x.y.z/24.
> For example, the remote subnet might be 10.88.0.0/24 and I would
> access IP addresses in the range 10.88.0.1 through 10.88.0.255. When
> a particular VPN connection is established, my local routing table (as
> the client) is modified with the following entries:
>
> Network Destination Netmask Gateway Interface
> Metric
> 10.0.0.0 255.0.0.0 10.88.0.80
> 10.88.0.81 21
> 10.88.0.81 255.255.255.255 On-link
> 10.88.0.81 276
>
> This works just fine for one connection. Notice, however, that the
> routing table entry states that the remote subnet is 10.0.0.0/8.
> According to this post:
>
> http://groups.google.com/group/micro...531033487b698f
>
> "Since the subnet mask depends only on the received IP it uses the old
> class rules. So if it gets a 192.168.x.y address it uses a 24-bit
> mask. If it gets a 10.x.y.z address it uses an 8-bit mask."
>
> The problem arises when I establish an additional VPN connection to
> any 10.x.y.z/24 subnet, for example, 10.88.1.0/24. The only network
> that is accessible is the first. I need a way to convey to Windows
> that in fact the remote network is not a /8, it is a /24, so that both
> networks are accessible over VPN concurrently.
>
> For each connection, the "use default gateway" option is unchecked.
> It doesn't appear that there are any other significant connection
> options for the routing of a VPN connection.
>
> Does anyone know of a way to make this work?
>

On Mar 13, 11:40*pm, "Bill Grant" <not.available@online> wrote:
> * *No there isn't really any way around that problem. The dialup client was
> designed to allow a remote user to connect to a LAN and access the resources
> there. It was not designed to allow simultaneous access to many different
> sites. You have very limited options. It really boils down to having a
> default route to the remote server or a subnet route. See KB 254231.
>
> "Mike Petito" <petit...@gmail.com> wrote in message
>
> news:0775aa5a-07e7-4510-ad90-(E-Mail Removed)...
>
> > From my development machine running Windows Vista, I often have to
> > establish multiple VPN connections to Windows 2003 servers on
> > different networks (i.e. for maintenance at different hosting
> > environments).
>
> > In each case, the remote subnet that I connect to is a 10.x.y.z/24.
> > For example, the remote subnet might be 10.88.0.0/24 and I would
> > access IP addresses in the range 10.88.0.1 through 10.88.0.255. *When
> > a particular VPN connection is established, my local routing table (as
> > the client) is modified with the following entries:
>
> > Network Destination * * * *Netmask * * * * *Gateway * * * Interface
> > Metric
> > * * * * * 10.0.0.0 * * * * * * 255.0.0.0 * * * * 10.88.0.80
> > 10.88.0.81 * * 21
> > * * * 10.88.0.81 * 255.255.255.255 * * * * * *On-link
> > 10.88.0.81 * *276
>
> > This works just fine for one connection. *Notice, however, that the
> > routing table entry states that the remote subnet is 10.0.0.0/8.
> > According to this post:
>
> >http://groups.google.com/group/micro....server.networ...
>
> > "Since the subnet mask depends only on the received IP it uses the old
> > class rules. So if it gets a 192.168.x.y address it uses a 24-bit
> > mask. If it gets a 10.x.y.z address it uses an 8-bit mask."
>
> > The problem arises when I establish an additional VPN connection to
> > any 10.x.y.z/24 subnet, for example, 10.88.1.0/24. *The only network
> > that is accessible is the first. *I need a way to convey to Windows
> > that in fact the remote network is not a /8, it is a /24, so that both
> > networks are accessible over VPN concurrently.
>
> > For each connection, the "use default gateway" option is unchecked.
> > It doesn't appear that there are any other significant connection
> > options for the routing of a VPN connection.
>
> > Does anyone know of a way to make this work?

That seems pretty amazing to me... if it was not designed to allow
simultaneous access to many different sites, then why does Windows let
me establish many concurrent VPN connections?

I realize that I can modify the routing table manually to make any
number of connections work. In my example above, I would have to
perform the following route operations from within an escalated
command prompt:

[Connect VPN to 10.88.0.0/8 subnet]
route delete 10.0.0.0
route add 10.88.0.0 MASK 255.255.255.0 <gateway IP> IF <interface ID
VPN #1>

[Connect VPN to 10.88.1.0/8 subnet]
route delete 10.0.0.0
route add 10.88.1.0 MASK 255.255.255.0 <gateway IP> IF <interface ID
VPN #2>

This becomes only slightly obnoxious, depending on how many times
throughout the day I need to connect to various sites.

Using procmon, I was able to monitor the registry activity that occurs
while establishing a VPN connection, and notice the following string
value being assigned the mask 255.0.0.0:
HKLM\System\CurrentControlSet\Services\Tcpip\Param eters\Interfaces
\<Interface GUID>\DhcpSubnetMask

However, this entire key appears to be reset every time the VPN
connection is established.

I suppose it is asking too much to be able to define properties of the
remote subnet for a particular VPN connection? I can envision several
useful enhancements, including the ability to define any number of
subnets that should be accessed across a particular VPN connection.
Maybe I need to setup a VPN gateway on a Linux box. I'm sure I'm not
the only person with such problems...

Hi, Mike.

No, you are not imagining things.

Microsoft programmers SEVERLY damaged the VPN Client in Vista and Server 2008.

.... and yes, the original MS VPN Client was designed to allow you to
establish more than one simultaneous VPN connection (limited to two in
workstation products such as Windows XP, etc. - Refer to Microsoft's product
documentation for more information.)

The problem you are experiencing is due to a flaw in Vista's AND Server
2008's implementation of the MS VPN Client.

With Windows 2000, XP, and 2003 Server the VPN client would receive the DNS
server, "connection specific" DNS domain suffix, and the appropriate Subnet
Mask from the DHCP server at the remote (VPN Server) side (if a DHCP Server
was used and the RRAS router's DHCP Relay was configured correctly).

What is happening with Vista and Server 2008 is that the code of the VPN
client is giving you a Subnet mask based on the first Octet of the IP address
that it receives, instead of obtaining the mask by query as it does in
Windows XP. (It also writes the DNS Server addresses to the registry in
reverse order from the order the server side issues... not to mention that,
in several scenarios, it ignores the DNS Domain name that is given to it.)

Microsoft has been notified of this many times, by many people (myself
included) but I still have not found a fix for it, short of manually altering
the routing table after you establish the VPN connection. SP1 for Vista did
not correct the problem, either.

I have also called in a complaint to Microsoft's customer service center
earlier this week.

We all need to apply pressure to Microsoft to fix what they broke! I am
advising all of my customers with field reps who VPN into their central
offices to NOT upgrade to Vista, until Microsoft fixes their problem with the
VPN client.

For my clients who are purchasing new laptops for their field reps who need
VPN capability, I am advising them to use Linux on the laptops, and deploy
Citrix on their servers. The Linux distros that I have tested have a working
VPN Client.

I have Vista Ultimate x64 on my machine, and I have written a script that
corrects the DNS issues after VPN connection. I'm also working on a script
that will correct the subnet mask issue.

Since I am not a big-shot developer working for Microsoft, it took me about
a week to perfect my DNS script. It should take me about the same amount of
time to script the subnet mask fix.

Interesting... if I can fix the DNS issues in Microsoft's VPN Client in one
week, why has Microsoft STILL NOT fixed it after 1.5 yesrs?

I think they have lost their expertise in networking.

I hope someone can get Microsoft to fix their broken code... until then, I
wish you well.

RLTusch

"Mike Petito" wrote:

> On Mar 13, 11:40 pm, "Bill Grant" <not.available@online> wrote:
> > No there isn't really any way around that problem. The dialup client was
> > designed to allow a remote user to connect to a LAN and access the resources
> > there. It was not designed to allow simultaneous access to many different
> > sites. You have very limited options. It really boils down to having a
> > default route to the remote server or a subnet route. See KB 254231.
> >
> > "Mike Petito" <petit...@gmail.com> wrote in message
> >
> > news:0775aa5a-07e7-4510-ad90-(E-Mail Removed)...
> >
> > > From my development machine running Windows Vista, I often have to
> > > establish multiple VPN connections to Windows 2003 servers on
> > > different networks (i.e. for maintenance at different hosting
> > > environments).
> >
> > > In each case, the remote subnet that I connect to is a 10.x.y.z/24.
> > > For example, the remote subnet might be 10.88.0.0/24 and I would
> > > access IP addresses in the range 10.88.0.1 through 10.88.0.255. When
> > > a particular VPN connection is established, my local routing table (as
> > > the client) is modified with the following entries:
> >
> > > Network Destination Netmask Gateway Interface
> > > Metric
> > > 10.0.0.0 255.0.0.0 10.88.0.80
> > > 10.88.0.81 21
> > > 10.88.0.81 255.255.255.255 On-link
> > > 10.88.0.81 276
> >
> > > This works just fine for one connection. Notice, however, that the
> > > routing table entry states that the remote subnet is 10.0.0.0/8.
> > > According to this post:
> >
> > >http://groups.google.com/group/micro....server.networ...
> >
> > > "Since the subnet mask depends only on the received IP it uses the old
> > > class rules. So if it gets a 192.168.x.y address it uses a 24-bit
> > > mask. If it gets a 10.x.y.z address it uses an 8-bit mask."
> >
> > > The problem arises when I establish an additional VPN connection to
> > > any 10.x.y.z/24 subnet, for example, 10.88.1.0/24. The only network
> > > that is accessible is the first. I need a way to convey to Windows
> > > that in fact the remote network is not a /8, it is a /24, so that both
> > > networks are accessible over VPN concurrently.
> >
> > > For each connection, the "use default gateway" option is unchecked.
> > > It doesn't appear that there are any other significant connection
> > > options for the routing of a VPN connection.
> >
> > > Does anyone know of a way to make this work?
>
> That seems pretty amazing to me... if it was not designed to allow
> simultaneous access to many different sites, then why does Windows let
> me establish many concurrent VPN connections?
>
> I realize that I can modify the routing table manually to make any
> number of connections work. In my example above, I would have to
> perform the following route operations from within an escalated
> command prompt:
>
> [Connect VPN to 10.88.0.0/8 subnet]
> route delete 10.0.0.0
> route add 10.88.0.0 MASK 255.255.255.0 <gateway IP> IF <interface ID
> VPN #1>
>
> [Connect VPN to 10.88.1.0/8 subnet]
> route delete 10.0.0.0
> route add 10.88.1.0 MASK 255.255.255.0 <gateway IP> IF <interface ID
> VPN #2>
>
> This becomes only slightly obnoxious, depending on how many times
> throughout the day I need to connect to various sites.
>
> Using procmon, I was able to monitor the registry activity that occurs
> while establishing a VPN connection, and notice the following string
> value being assigned the mask 255.0.0.0:
> HKLM\System\CurrentControlSet\Services\Tcpip\Param eters\Interfaces
> \<Interface GUID>\DhcpSubnetMask
>
> However, this entire key appears to be reset every time the VPN
> connection is established.
>
> I suppose it is asking too much to be able to define properties of the
> remote subnet for a particular VPN connection? I can envision several
> useful enhancements, including the ability to define any number of
> subnets that should be accessed across a particular VPN connection.
> Maybe I need to setup a VPN gateway on a Linux box. I'm sure I'm not
> the only person with such problems...
>

That is not really true. There is no way that a remote client can receive
its network config from a DHCP server. If you are going to complain to
Microsoft you had better read the documentation and know what you are
talking about.

The remote client gets its network config from the remote access server
as part of the ppp negotiation. It has to work that way because the config
is only valid for the duration of the connection, not for the lease time of
DHCP. The server leases the addresses from DHCP and uses them instead of a
static pool.

What the remote client can do (if it has the ability) is send a
dhcpinform request after it connects to obtain additional information. If
Vista doesn't do this then this is the area you need to look at, not the
setting up of the remote connection.

"RLTusch" <(E-Mail Removed)> wrote in message
news:1DDFC71A-ACF4-41E7-836E-(E-Mail Removed)...
> Hi, Mike.
>
> No, you are not imagining things.
>
> Microsoft programmers SEVERLY damaged the VPN Client in Vista and Server
> 2008.
>
> ... and yes, the original MS VPN Client was designed to allow you to
> establish more than one simultaneous VPN connection (limited to two in
> workstation products such as Windows XP, etc. - Refer to Microsoft's
> product
> documentation for more information.)
>
> The problem you are experiencing is due to a flaw in Vista's AND Server
> 2008's implementation of the MS VPN Client.
>
> With Windows 2000, XP, and 2003 Server the VPN client would receive the
> DNS
> server, "connection specific" DNS domain suffix, and the appropriate
> Subnet
> Mask from the DHCP server at the remote (VPN Server) side (if a DHCP
> Server
> was used and the RRAS router's DHCP Relay was configured correctly).
>
> What is happening with Vista and Server 2008 is that the code of the VPN
> client is giving you a Subnet mask based on the first Octet of the IP
> address
> that it receives, instead of obtaining the mask by query as it does in
> Windows XP. (It also writes the DNS Server addresses to the registry in
> reverse order from the order the server side issues... not to mention
> that,
> in several scenarios, it ignores the DNS Domain name that is given to it.)
>
> Microsoft has been notified of this many times, by many people (myself
> included) but I still have not found a fix for it, short of manually
> altering
> the routing table after you establish the VPN connection. SP1 for Vista
> did
> not correct the problem, either.
>
> I have also called in a complaint to Microsoft's customer service center
> earlier this week.
>
> We all need to apply pressure to Microsoft to fix what they broke! I am
> advising all of my customers with field reps who VPN into their central
> offices to NOT upgrade to Vista, until Microsoft fixes their problem with
> the
> VPN client.
>
> For my clients who are purchasing new laptops for their field reps who
> need
> VPN capability, I am advising them to use Linux on the laptops, and deploy
> Citrix on their servers. The Linux distros that I have tested have a
> working
> VPN Client.
>
> I have Vista Ultimate x64 on my machine, and I have written a script that
> corrects the DNS issues after VPN connection. I'm also working on a
> script
> that will correct the subnet mask issue.
>
> Since I am not a big-shot developer working for Microsoft, it took me
> about
> a week to perfect my DNS script. It should take me about the same amount
> of
> time to script the subnet mask fix.
>
> Interesting... if I can fix the DNS issues in Microsoft's VPN Client in
> one
> week, why has Microsoft STILL NOT fixed it after 1.5 yesrs?
>
> I think they have lost their expertise in networking.
>
> I hope someone can get Microsoft to fix their broken code... until then, I
> wish you well.
>
> RLTusch
>
> "Mike Petito" wrote:
>
>> On Mar 13, 11:40 pm, "Bill Grant" <not.available@online> wrote:
>> > No there isn't really any way around that problem. The dialup client
>> > was
>> > designed to allow a remote user to connect to a LAN and access the
>> > resources
>> > there. It was not designed to allow simultaneous access to many
>> > different
>> > sites. You have very limited options. It really boils down to having a
>> > default route to the remote server or a subnet route. See KB 254231.
>> >
>> > "Mike Petito" <petit...@gmail.com> wrote in message
>> >
>> > news:0775aa5a-07e7-4510-ad90-(E-Mail Removed)...
>> >
>> > > From my development machine running Windows Vista, I often have to
>> > > establish multiple VPN connections to Windows 2003 servers on
>> > > different networks (i.e. for maintenance at different hosting
>> > > environments).
>> >
>> > > In each case, the remote subnet that I connect to is a 10.x.y.z/24.
>> > > For example, the remote subnet might be 10.88.0.0/24 and I would
>> > > access IP addresses in the range 10.88.0.1 through 10.88.0.255. When
>> > > a particular VPN connection is established, my local routing table
>> > > (as
>> > > the client) is modified with the following entries:
>> >
>> > > Network Destination Netmask Gateway Interface
>> > > Metric
>> > > 10.0.0.0 255.0.0.0 10.88.0.80
>> > > 10.88.0.81 21
>> > > 10.88.0.81 255.255.255.255 On-link
>> > > 10.88.0.81 276
>> >
>> > > This works just fine for one connection. Notice, however, that the
>> > > routing table entry states that the remote subnet is 10.0.0.0/8.
>> > > According to this post:
>> >
>> > >http://groups.google.com/group/micro....server.networ...
>> >
>> > > "Since the subnet mask depends only on the received IP it uses the
>> > > old
>> > > class rules. So if it gets a 192.168.x.y address it uses a 24-bit
>> > > mask. If it gets a 10.x.y.z address it uses an 8-bit mask."
>> >
>> > > The problem arises when I establish an additional VPN connection to
>> > > any 10.x.y.z/24 subnet, for example, 10.88.1.0/24. The only network
>> > > that is accessible is the first. I need a way to convey to Windows
>> > > that in fact the remote network is not a /8, it is a /24, so that
>> > > both
>> > > networks are accessible over VPN concurrently.
>> >
>> > > For each connection, the "use default gateway" option is unchecked.
>> > > It doesn't appear that there are any other significant connection
>> > > options for the routing of a VPN connection.
>> >
>> > > Does anyone know of a way to make this work?
>>
>> That seems pretty amazing to me... if it was not designed to allow
>> simultaneous access to many different sites, then why does Windows let
>> me establish many concurrent VPN connections?
>>
>> I realize that I can modify the routing table manually to make any
>> number of connections work. In my example above, I would have to
>> perform the following route operations from within an escalated
>> command prompt:
>>
>> [Connect VPN to 10.88.0.0/8 subnet]
>> route delete 10.0.0.0
>> route add 10.88.0.0 MASK 255.255.255.0 <gateway IP> IF <interface ID
>> VPN #1>
>>
>> [Connect VPN to 10.88.1.0/8 subnet]
>> route delete 10.0.0.0
>> route add 10.88.1.0 MASK 255.255.255.0 <gateway IP> IF <interface ID
>> VPN #2>
>>
>> This becomes only slightly obnoxious, depending on how many times
>> throughout the day I need to connect to various sites.
>>
>> Using procmon, I was able to monitor the registry activity that occurs
>> while establishing a VPN connection, and notice the following string
>> value being assigned the mask 255.0.0.0:
>> HKLM\System\CurrentControlSet\Services\Tcpip\Param eters\Interfaces
>> \<Interface GUID>\DhcpSubnetMask
>>
>> However, this entire key appears to be reset every time the VPN
>> connection is established.
>>
>> I suppose it is asking too much to be able to define properties of the
>> remote subnet for a particular VPN connection? I can envision several
>> useful enhancements, including the ability to define any number of
>> subnets that should be accessed across a particular VPN connection.
>> Maybe I need to setup a VPN gateway on a Linux box. I'm sure I'm not
>> the only person with such problems...
>>

Well, aren't we the hothead...

Perhaps you should read before opening your proverbial mouth...

I wrote:

"With Windows 2000, XP, and 2003 Server the VPN client would receive the DNS
server, "connection specific" DNS domain suffix, and the appropriate Subnet
Mask from the DHCP server at the remote (VPN Server) side (if a DHCP Server
was used and the RRAS router's DHCP Relay was configured correctly). "

How do you figure that process works? Oh, could it be the dhcpinform that
you were mentioning?

Again, as I said, the VPN Client gets that information from the DHCP Server
(via dhcpinform) if (as I also stated) the RRAS Server was set to use DHCP
and the DHCP relay was properly configured.

But it was nice of you to confirm what I had already told everybody. I
appreciate that you confirmed that I do actualy know what I'm talking about.

Anyway, you wrote:

"If Vista doesn't do this then this is the area you need to look at, not the
setting up of the remote connection."

In response to me writing:

"The problem you are experiencing is due to a flaw in Vista's AND Server
2008's implementation of the MS VPN Client."

Once again, thank you for confirming that I have a clue what I'm talking
about.

(You might want to learn to be more careful and patient when you are reading
someone else's posts in the future... it will save you some embarrassment.)


By the way, you wrote in your original post:

"The dialup client was designed to allow a remote user to connect to a LAN
and access the resources there. It was not designed to allow simultaneous
access to many different sites."

You may want to read Microsoft's documentation before making a statement
like that. Although you are right about the "many" simultaneous connections
on a MS workstation OS (the limit is, in fact, two simultaneous connections -
see my original post) it is most definately able to handle many simultaneous
connections on a Server OS, which is how I am maintaining 12 simultaneous VPN
connections at this very monent with NO problems from my server.

If you are interested in conducting two simultaneous VPN connections from a
MS workstation OS, try using a technique called "split tunneling" on the
server side. Then, you clear the "Use default gateway on remote network"
setting on the client side. (But that is what leads to Mike's problem under
Vista.)

Once again, thank you for validating my post as being accurate.

Have a great day!

RLTusch


"Bill Grant" wrote:

> That is not really true. There is no way that a remote client can receive
> its network config from a DHCP server. If you are going to complain to
> Microsoft you had better read the documentation and know what you are
> talking about.
>
> The remote client gets its network config from the remote access server
> as part of the ppp negotiation. It has to work that way because the config
> is only valid for the duration of the connection, not for the lease time of
> DHCP. The server leases the addresses from DHCP and uses them instead of a
> static pool.
>
> What the remote client can do (if it has the ability) is send a
> dhcpinform request after it connects to obtain additional information. If
> Vista doesn't do this then this is the area you need to look at, not the
> setting up of the remote connection.
>
> "RLTusch" <(E-Mail Removed)> wrote in message
> news:1DDFC71A-ACF4-41E7-836E-(E-Mail Removed)...
> > Hi, Mike.
> >
> > No, you are not imagining things.
> >
> > Microsoft programmers SEVERLY damaged the VPN Client in Vista and Server
> > 2008.
> >
> > ... and yes, the original MS VPN Client was designed to allow you to
> > establish more than one simultaneous VPN connection (limited to two in
> > workstation products such as Windows XP, etc. - Refer to Microsoft's
> > product
> > documentation for more information.)
> >
> > The problem you are experiencing is due to a flaw in Vista's AND Server
> > 2008's implementation of the MS VPN Client.
> >
> > With Windows 2000, XP, and 2003 Server the VPN client would receive the
> > DNS
> > server, "connection specific" DNS domain suffix, and the appropriate
> > Subnet
> > Mask from the DHCP server at the remote (VPN Server) side (if a DHCP
> > Server
> > was used and the RRAS router's DHCP Relay was configured correctly).
> >
> > What is happening with Vista and Server 2008 is that the code of the VPN
> > client is giving you a Subnet mask based on the first Octet of the IP
> > address
> > that it receives, instead of obtaining the mask by query as it does in
> > Windows XP. (It also writes the DNS Server addresses to the registry in
> > reverse order from the order the server side issues... not to mention
> > that,
> > in several scenarios, it ignores the DNS Domain name that is given to it.)
> >
> > Microsoft has been notified of this many times, by many people (myself
> > included) but I still have not found a fix for it, short of manually
> > altering
> > the routing table after you establish the VPN connection. SP1 for Vista
> > did
> > not correct the problem, either.
> >
> > I have also called in a complaint to Microsoft's customer service center
> > earlier this week.
> >
> > We all need to apply pressure to Microsoft to fix what they broke! I am
> > advising all of my customers with field reps who VPN into their central
> > offices to NOT upgrade to Vista, until Microsoft fixes their problem with
> > the
> > VPN client.
> >
> > For my clients who are purchasing new laptops for their field reps who
> > need
> > VPN capability, I am advising them to use Linux on the laptops, and deploy
> > Citrix on their servers. The Linux distros that I have tested have a
> > working
> > VPN Client.
> >
> > I have Vista Ultimate x64 on my machine, and I have written a script that
> > corrects the DNS issues after VPN connection. I'm also working on a
> > script
> > that will correct the subnet mask issue.
> >
> > Since I am not a big-shot developer working for Microsoft, it took me
> > about
> > a week to perfect my DNS script. It should take me about the same amount
> > of
> > time to script the subnet mask fix.
> >
> > Interesting... if I can fix the DNS issues in Microsoft's VPN Client in
> > one
> > week, why has Microsoft STILL NOT fixed it after 1.5 yesrs?
> >
> > I think they have lost their expertise in networking.
> >
> > I hope someone can get Microsoft to fix their broken code... until then, I
> > wish you well.
> >
> > RLTusch
> >
> > "Mike Petito" wrote:
> >
> >> On Mar 13, 11:40 pm, "Bill Grant" <not.available@online> wrote:
> >> > No there isn't really any way around that problem. The dialup client
> >> > was
> >> > designed to allow a remote user to connect to a LAN and access the
> >> > resources
> >> > there. It was not designed to allow simultaneous access to many
> >> > different
> >> > sites. You have very limited options. It really boils down to having a
> >> > default route to the remote server or a subnet route. See KB 254231.
> >> >
> >> > "Mike Petito" <petit...@gmail.com> wrote in message
> >> >
> >> > news:0775aa5a-07e7-4510-ad90-(E-Mail Removed)...
> >> >
> >> > > From my development machine running Windows Vista, I often have to
> >> > > establish multiple VPN connections to Windows 2003 servers on
> >> > > different networks (i.e. for maintenance at different hosting
> >> > > environments).
> >> >
> >> > > In each case, the remote subnet that I connect to is a 10.x.y.z/24.
> >> > > For example, the remote subnet might be 10.88.0.0/24 and I would
> >> > > access IP addresses in the range 10.88.0.1 through 10.88.0.255. When
> >> > > a particular VPN connection is established, my local routing table
> >> > > (as
> >> > > the client) is modified with the following entries:
> >> >
> >> > > Network Destination Netmask Gateway Interface
> >> > > Metric
> >> > > 10.0.0.0 255.0.0.0 10.88.0.80
> >> > > 10.88.0.81 21
> >> > > 10.88.0.81 255.255.255.255 On-link
> >> > > 10.88.0.81 276
> >> >
> >> > > This works just fine for one connection. Notice, however, that the
> >> > > routing table entry states that the remote subnet is 10.0.0.0/8.
> >> > > According to this post:
> >> >
> >> > >http://groups.google.com/group/micro....server.networ...
> >> >
> >> > > "Since the subnet mask depends only on the received IP it uses the
> >> > > old
> >> > > class rules. So if it gets a 192.168.x.y address it uses a 24-bit
> >> > > mask. If it gets a 10.x.y.z address it uses an 8-bit mask."
> >> >
> >> > > The problem arises when I establish an additional VPN connection to
> >> > > any 10.x.y.z/24 subnet, for example, 10.88.1.0/24. The only network
> >> > > that is accessible is the first. I need a way to convey to Windows
> >> > > that in fact the remote network is not a /8, it is a /24, so that
> >> > > both
> >> > > networks are accessible over VPN concurrently.
> >> >
> >> > > For each connection, the "use default gateway" option is unchecked.
> >> > > It doesn't appear that there are any other significant connection
> >> > > options for the routing of a VPN connection.
> >> >
> >> > > Does anyone know of a way to make this work?
> >>
> >> That seems pretty amazing to me... if it was not designed to allow
> >> simultaneous access to many different sites, then why does Windows let
> >> me establish many concurrent VPN connections?
> >>
> >> I realize that I can modify the routing table manually to make any
> >> number of connections work. In my example above, I would have to
> >> perform the following route operations from within an escalated
> >> command prompt:
> >>
> >> [Connect VPN to 10.88.0.0/8 subnet]
> >> route delete 10.0.0.0
> >> route add 10.88.0.0 MASK 255.255.255.0 <gateway IP> IF <interface ID
> >> VPN #1>
> >>
> >> [Connect VPN to 10.88.1.0/8 subnet]
> >> route delete 10.0.0.0
> >> route add 10.88.1.0 MASK 255.255.255.0 <gateway IP> IF <interface ID
> >> VPN #2>
> >>
> >> This becomes only slightly obnoxious, depending on how many times
> >> throughout the day I need to connect to various sites.
> >>
> >> Using procmon, I was able to monitor the registry activity that occurs
> >> while establishing a VPN connection, and notice the following string
> >> value being assigned the mask 255.0.0.0:
> >> HKLM\System\CurrentControlSet\Services\Tcpip\Param eters\Interfaces
> >> \<Interface GUID>\DhcpSubnetMask
> >>
> >> However, this entire key appears to be reset every time the VPN
> >> connection is established.
> >>
> >> I suppose it is asking too much to be able to define properties of the
> >> remote subnet for a particular VPN connection? I can envision several
> >> useful enhancements, including the ability to define any number of
> >> subnets that should be accessed across a particular VPN connection.
> >> Maybe I need to setup a VPN gateway on a Linux box. I'm sure I'm not
> >> the only person with such problems...
> >>
>
>