Inconsistent subnet mask assigned for VPN connection in RRAS

We have a win2k3 RRAS server serving up VPN connectivity. Addresses
are handed out via DHCP relay agent and the network address range is
10.0.96.0/255.255.252.0. When VPN clients connect, they receive an
address in the 10.0.96.0 range with subnet 255.255.255.255 and no
gateway (when the "Use default gateway on remote network" checkbox is
unchecked). Quite often, clients are unable to access server resources
in the 10.0.98.0 range. When we do a route print, we see something
like this:

10.0.96.0 255.255.255.0 10.0.96.4 10.0.96.4 1

When it does work, we see:

10.0.96.0 255.255.252.0 10.0.96.4 10.0.96.4 1

I am unable to determine why sometimes it hands out the correct subnet
and other times not. We can work around it buy checking the "Use
Default Gateweay" but we'd rather not have the clients' traffic routed
through our slow internet connection (which invariably it ends up
doing). We can also blow away the 10.0.96.0 route and add the
corrected subnet mask manually. However, we would like this to "just
work" without resorting to rebuilding the route on the client end via
batch script.

I read the thread at
http://groups.google.com/group/micro...531033487b698f

and it seems that this is by design. However, it doesn't do it
consistently - sometimes it is /24, others it is /22.

How can we get it so that it comes out /22 all the time?




Thanks so much!

<Peakbagger66_r3m0v3_th15_@hotmail.com> wrote in message
news:(E-Mail Removed)...
> We have a win2k3 RRAS server serving up VPN connectivity. Addresses
> are handed out via DHCP relay agent and the network address range is
> 10.0.96.0/255.255.252.0. When VPN clients connect, they receive an
> address in the 10.0.96.0 range with subnet 255.255.255.255 and

It is supposed to be that way

> gateway (when the "Use default gateway on remote network" checkbox is
> unchecked).

Leave the box checked. It needs that.

> and it seems that this is by design. However, it doesn't do it
> consistently - sometimes it is /24, others it is /22.
>
> How can we get it so that it comes out /22 all the time?

It isn't supposed to.

Make sure the VPN Clients also receive the DNS and WINS Settings that are
correct for the LAN the are "VPN'ing" into.


--
Phillip Windell
www.wandtv.com

The views expressed, are my own and not those of my employer, or Microsoft,
or anyone else associated with me, including my cats.
-----------------------------------------------------

<Peakbagger66_r3m0v3_th15_@hotmail.com> wrote in message
news:(E-Mail Removed)...
> We have a win2k3 RRAS server serving up VPN connectivity. Addresses
> are handed out via DHCP relay agent and the network address range is
> 10.0.96.0/255.255.252.0. When VPN clients connect, they receive an
> address in the 10.0.96.0 range with subnet 255.255.255.255 and no
> gateway (when the "Use default gateway on remote network" checkbox is
> unchecked). Quite often, clients are unable to access server resources
> in the 10.0.98.0 range. When we do a route print, we see something
> like this:
>
> 10.0.96.0 255.255.255.0 10.0.96.4 10.0.96.4 1
>
> When it does work, we see:
>
> 10.0.96.0 255.255.252.0 10.0.96.4 10.0.96.4 1
>
> I am unable to determine why sometimes it hands out the correct subnet
> and other times not. We can work around it buy checking the "Use
> Default Gateweay" but we'd rather not have the clients' traffic routed
> through our slow internet connection (which invariably it ends up
> doing). We can also blow away the 10.0.96.0 route and add the
> corrected subnet mask manually. However, we would like this to "just
> work" without resorting to rebuilding the route on the client end via
> batch script.
>
> I read the thread at
> http://groups.google.com/group/micro...531033487b698f
>
> and it seems that this is by design. However, it doesn't do it
> consistently - sometimes it is /24, others it is /22.
>
> How can we get it so that it comes out /22 all the time?
>
>
>
>
> Thanks so much!


How many DHCP servers are on the network? Is it running on the router, as
well as on a Windows box? THere should never be any differences unless
something else is going on, such as multiple DHCP servers.

--
Ace

This posting is provided "AS-IS" with no warranties or guarantees and
confers no rights.

Ace Fekay, MCSE 2003 & 2000, MCSA 2003 & 2000, MCSA Messaging, MCT
Microsoft Certified Trainer
(E-Mail Removed)

For urgent issues, you may want to contact Microsoft PSS directly. Please
check http://support.microsoft.com for regional support phone numbers.

"Efficiency is doing things right; effectiveness is doing the right
things." - Peter F. Drucker
http://twitter.com/acefekay

<Peakbagger66_r3m0v3_th15_@hotmail.com> wrote in message
news:(E-Mail Removed)...
> We have a win2k3 RRAS server serving up VPN connectivity. Addresses
> are handed out via DHCP relay agent and the network address range is
> 10.0.96.0/255.255.252.0. When VPN clients connect, they receive an
> address in the 10.0.96.0 range with subnet 255.255.255.255 and no
> gateway (when the "Use default gateway on remote network" checkbox is
> unchecked). Quite often, clients are unable to access server resources
> in the 10.0.98.0 range. When we do a route print, we see something
> like this:
>
> 10.0.96.0 255.255.255.0 10.0.96.4 10.0.96.4 1
>
> When it does work, we see:
>
> 10.0.96.0 255.255.252.0 10.0.96.4 10.0.96.4 1
>
> I am unable to determine why sometimes it hands out the correct subnet
> and other times not. We can work around it buy checking the "Use
> Default Gateweay" but we'd rather not have the clients' traffic routed
> through our slow internet connection (which invariably it ends up
> doing). We can also blow away the 10.0.96.0 route and add the
> corrected subnet mask manually. However, we would like this to "just
> work" without resorting to rebuilding the route on the client end via
> batch script.
>
> I read the thread at
> http://groups.google.com/group/micro...531033487b698f
>
> and it seems that this is by design. However, it doesn't do it
> consistently - sometimes it is /24, others it is /22.
>
> How can we get it so that it comes out /22 all the time?
>
>
>
>
> Thanks so much!

First of all, your statement "Addresses are handed out via DHCP relay
agent" is not correct. A remote client does not get its network config from
DHCP. A remote client gets its network config from the RRAS server as part
of the PPP negotiation. If you have not provided a static pool of addresses,
RRAS obtains a batch of IPs from DHCP to use instead.

If you have a routed network, you should not be letting RRAS get its
address pool from DHCP. You should allocate a specific subnet to your
remotes (say 10.0.99.0/24) and route that network to your existing network
through the RRAS server (just as you would for a separate LAN segment). The
method you are using (remotes in the same IP subnet as the LAN machines) is
called on-subnet addressing and relies on the RRAS server doing proxy ARP on
the LAN for the remotes. It is a "quick fix" method introduced in the early
days of RRAS to allow remote clients to connect to the LAN without the
sysadmin having to worry about routing. Subnets are not really relevant
because no IP routing is actually being done. The RRAS server is simply
acting as a proxy for each remote client. It is not suitable for a routed
network.

If you have a routed network you need to use off-subnet addressing. All
remotes (and the "internal" interface in RRAS) are in their own IP subnet.
This subnet is regarded as another segment in your network which is routed
through the RRAS server. You need LAN routing enabled on the RRAS server.

"Bill Grant" <not.available@online> wrote in message
news:(E-Mail Removed)...
>
> If you have a routed network you need to use off-subnet addressing. All
> remotes (and the "internal" interface in RRAS) are in their own IP subnet.
> This subnet is regarded as another segment in your network which is routed
> through the RRAS server. You need LAN routing enabled on the RRAS server.


Actually that is my preferred method. It's more secure with the ability to
create access rules on their subnet. I also prefer to use hardware-based VPN
solutions anyway (Cisco ASAs). VPN pool is in it's own subnet, with rules
allowing access to the internal subnet(s).

Cheers!

Ace

On Fri, 8 May 2009 10:21:01 +1000, "Bill Grant" <not.available@online>
wrote:

>
>
><Peakbagger66_r3m0v3_th15_@hotmail.com> wrote in message
>news:(E-Mail Removed).. .

8<-------*SNIP*--------->8


>
> First of all, your statement "Addresses are handed out via DHCP relay
>agent" is not correct. A remote client does not get its network config from
>DHCP. A remote client gets its network config from the RRAS server as part
>of the PPP negotiation. If you have not provided a static pool of addresses,
>RRAS obtains a batch of IPs from DHCP to use instead.

Yes, I stand corrected :-)


>
> If you have a routed network, you should not be letting RRAS get its
>address pool from DHCP. You should allocate a specific subnet to your
>remotes (say 10.0.99.0/24) and route that network to your existing network
>through the RRAS server (just as you would for a separate LAN segment). The
>method you are using (remotes in the same IP subnet as the LAN machines) is
>called on-subnet addressing and relies on the RRAS server doing proxy ARP on
>the LAN for the remotes. It is a "quick fix" method introduced in the early
>days of RRAS to allow remote clients to connect to the LAN without the
>sysadmin having to worry about routing. Subnets are not really relevant
>because no IP routing is actually being done. The RRAS server is simply
>acting as a proxy for each remote client. It is not suitable for a routed
>network.
>
> If you have a routed network you need to use off-subnet addressing. All
>remotes (and the "internal" interface in RRAS) are in their own IP subnet.
>This subnet is regarded as another segment in your network which is routed
>through the RRAS server. You need LAN routing enabled on the RRAS server.
>
>

This is great advice. I will set up a test system and play with it. We
will probably implement this.


However, the question still stands, why is it that sometimes we get in
our routing table 255.255.252.0 and other times we get 255.255.255.0
for the same network?

On Thu, 7 May 2009 13:30:56 -0500, "Phillip Windell"
<(E-Mail Removed)> wrote:

><Peakbagger66_r3m0v3_th15_@hotmail.com> wrote in message
>news:(E-Mail Removed).. .
>> We have a win2k3 RRAS server serving up VPN connectivity. Addresses
>> are handed out via DHCP relay agent and the network address range is
>> 10.0.96.0/255.255.252.0. When VPN clients connect, they receive an
>> address in the 10.0.96.0 range with subnet 255.255.255.255 and
>
>It is supposed to be that way
>
>> gateway (when the "Use default gateway on remote network" checkbox is
>> unchecked).
>
>Leave the box checked. It needs that.

So the box should be checked. I think I can understand why this is a
security risk. Basically we are exposing the client workstation's
Internet connection (and whatever attendant security issues they might
have) to our network. However, in our business processes we need to be
able to connect to different networks, often simultaneously, playing
it "fast and loose". In practice, checking the box has caused problems
for remote workers who vpn into client sites and who need access to
the mothership.

>
>> and it seems that this is by design. However, it doesn't do it
>> consistently - sometimes it is /24, others it is /22.
>>
>> How can we get it so that it comes out /22 all the time?
>
>It isn't supposed to.
>

The fact that this *does* happen makes me hope that there is some
chance that we can make it happen at will.

>Make sure the VPN Clients also receive the DNS and WINS Settings that are
>correct for the LAN the are "VPN'ing" into.

<Peakbagger66_r3m0v3_th15_@hotmail.com> wrote in message
news:(E-Mail Removed)...
>>Leave the box checked. It needs that.
>
> So the box should be checked. I think I can understand why this is a
> security risk. Basically we are exposing the client workstation's
> Internet connection (and whatever attendant security issues they might
> have) to our network. However, in our business processes we need to be
> able to connect to different networks, often simultaneously, playing
> it "fast and loose". In practice, checking the box has caused problems
> for remote workers who vpn into client sites and who need access to
> the mothership.

Security is not the only aspect.
If you do not check the box the VPN client is limited to the Subnet that the
VPN'ed into and cannot reach other segments on the LAN that they connected
to.

>>
>>> and it seems that this is by design. However, it doesn't do it
>>> consistently - sometimes it is /24, others it is /22.
>>>
>>> How can we get it so that it comes out /22 all the time?
>>
>>It isn't supposed to.
>>
>
> The fact that this *does* happen makes me hope that there is some
> chance that we can make it happen at will.

I don't know for surer about that one.


--
Phillip Windell
www.wandtv.com

The views expressed, are my own and not those of my employer, or Microsoft,
or anyone else associated with me, including my cats.
-----------------------------------------------------

<Peakbagger66_r3m0v3_th15_@hotmail.com> wrote in message
news:(E-Mail Removed)...
>
> However, the question still stands, why is it that sometimes we get in
> our routing table 255.255.252.0 and other times we get 255.255.255.0
> for the same network?



If you re-created or re-configured RRAS, that is if you have the ability to
do so, does it still occur? Maybe try to setup RRAS/VPN on another server
and test it.

Either way, it shouldn't be happening.

Ace

Thanks Ace, we intend on doing just that in our lab. It's got my
curiousity peaked to say the least. I liked Bill Grant's suggestion
regarding a seperate subnet for the RAS clients but I still want to
see why this is happening...



On Sat, 9 May 2009 10:20:39 -0400, "Ace Fekay [Microsoft Certified
Trainer]" <(E-Mail Removed)> wrote:

><Peakbagger66_r3m0v3_th15_@hotmail.com> wrote in message
>news:(E-Mail Removed).. .
>>
>> However, the question still stands, why is it that sometimes we get in
>> our routing table 255.255.252.0 and other times we get 255.255.255.0
>> for the same network?
>
>
>
>If you re-created or re-configured RRAS, that is if you have the ability to
>do so, does it still occur? Maybe try to setup RRAS/VPN on another server
>and test it.
>
>Either way, it shouldn't be happening.
>
>Ace