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/micr...2a1250dce0/f5531033487b698f?#f5531033487b698f

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!

 

It is supposed to be that way

Leave the box checked. It needs that.

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.
-----------------------------------------------------

 

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


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

 

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.

 

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

 

Yes, I stand corrected

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?

 

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.

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

 

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.

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.
-----------------------------------------------------

 

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...

 

Just thinking through this - will this method fail if the " Use
Default gateway" in the TCPIP properties of the client connectoid is
deselected?

 

I can understand the curiosity because this is not normal. I can't figure out why it would be causing this on your part.

Ace

 

Deselecting it will allow your machine to access anything other than corporate resources, such as the internet, to use it's own gateway. In the Cisco setup, we set this up on the firewall side so when the connection is made, the VPN user will not be using the corporate infrastructure for internet use while connected.

Ace