VPN setup Server/Routing issues in Cloud

You have to add the DHCP Agent in RRAS and tell the Agent what DHCP Server to look to.  I think RRAS refers to it as a Protocol,..so you  have to "add a new protocol" and choose the DHCP Agent.  It may be called a service,..but I thought is was protocol (it's been a while).

You networks are also overloaded.  Segments should never have more than 300 hosts,...so the Masks should never be lower than 255.255.255.0 (24/bit, 254 Hosts)

You add the DHCP Agent from within the RRAS MMC

Thanks. I have added the DHCP IP as the relay. It seems that the DHCP never gets the request from The VPN server. I think that it won't hand out the 192.168.10.x because of routing. The IP's on the 10 range are given to me from Rackspace. I can not change these.

Do I need to add a 192.168.10.x as an IP on the WAN or LAN adapter? Even when I statically assign the address using the RRAS MMC and selecting "Range", the client will pick up a 192 address but I can not route at all. I have looked over the DHCP relay info from MS, and taken what seem to be appropriate steps for adding the relay server to no avail.

Actually it should still work without the Agent. The Agent only adds the ability of the Client to gain other DHCP Options.  The way Clients get IP Specs over RRAS is by RRAS proxying the address to the Client (it is not really DHCP).  RRAS grabs a block of addresses from the DHCP Server,..I believe it does it according to the number or Remote Access Ports listed in the Ports Node in the RRAS MMC.  When the Client connects they take up on of those "Remote Access Ports" and then inheirt the basic TCP/IP Specs from that.  The DHCP Agent then allows them to get additional DHCP Options beyond that.

I don't have a 2008 box to verify against but RRAS will use the DHCP Server that is available according to the Interface you tell it to use.  It uses a generic name of "Internal" to represent the normal Nic the DHCP Server uses and it will use the Scope on that DHCP Server that match the TCP/IP Specs used by that Server Nic.

Why is it so complicated?  Because the Client do not go to the DHCP Service.  RRAS goes to the DHCP and gathers what it wants ahead of time,...then the Clients just come to RRAS and RRAS gives them what it wants to give them.

Another thing to keep in mind is that if the Clients disable the "Use gateway on remote network" in their Local DUN Settings they will never be able to route past the subnet that they immediately connected into.  That setting must remain enabled, which allows the Clients to route using the Default Gateway that the RRAS Server uses.   Remember the Remote Access Client do not use their own Local Default Gateway,..their Default Gateway dynamically switches to the IP# of their Remote Access Virtual Adapter which automatically passes everything to the RRAS Server,...which effectively makes the Default Gateway of the RRAS Box be the Clients Default Gateway.   That is why if you do an IPCONFIG on an active Remote Access Client the Mask is always 255.255.255.255 and the Gateway is the same IP as the Adapter IP recieved when they made the connection,...the whole thing just sort of "piggy-backs" off of what the RRAS box is doing.

I have seen RRAS do this on my other physical boxes, but it does not seem to reserve any IP's from this server. I wonder if it does not know it should pass out a 192.168.10.x because the request is sent from a 10.182.x.x  address from the VPN server to the DHCP server. I can ping the DHCP server. on the 10.182.x.x VPN server.

Thanks for the help here, this should be easy, but I am stuck..

You can't use 192.168 because the RRAS box's Nic is not on that segment.   I assume the RRAS box only has one Nic facing the LAN.  It is normal for them to have two but the other would be internet facing as is irrelevant.  If the LAN Nic is 10.182.x.x then that is going to be the same Scope that it gathers its IP Inventory from,...and that inventory is where the Clients will get their spec.

So, yes, you are wasting you time. Worse yet you are wasting your time worrying about something that you should not even care about in the first place.   It should not matter squat what IP Specs the Client gets as long as whatever they DO get allows them to function properly and to route to where they have go.

I agree, so since rackspace will not allow me to use the 10 network for my VPN clients what do I do?

RRAS is only one small piece in a much bigger puzzle.

If you over-all LAN/WAN design has flaws you just get a domino effect of failures and you end up chasing symptoms of problems rather than the real problems causing the symptoms.  You already have design flaws in that you have you subnets too large (over-loaded),...that by itself wont' cause these problems but if one bad choice was made then their could have been other bad choices made that we haven't seen yet that do cause problems.

I am stuck with what Rackspace assigns on the LAN, nothing I can do about this.

I am only given 1 static IP per box from rackspace. That is why I wanted to use the 192.168 range for the remote clients. Is there someway to route that network to the 10?

Rackspace would have to supply the VPN solution then,...I suppose.   I'm sure they would charge an additional fee for it.

This is why I can't stand the whole "Cloud" mentality that the whole industry seems to be on a mad dash for.  It is just the latest buzzword for "Outsourcing".  So when ever you see the term "The Cloud" just erase the term and replace it with "Outsourcing" because that is all it is.  Marketing to me is summed up as people getting up every morning and asking "How can we fool 'em today?"

If it were me I would see if there was a way to have a Site-to-Site VPN between the LAN and the network that the resources are on at Rackspace.   Then once communication between the two LANs functioned properly then it would be a simple thing to have Clients remote into your local LAN and then they could access anything that the LAN can access and Rackspace would see no difference between those Clients and any other machine on your Local LAN.  But again,..there is a lot I don't know about this situation.  I don't use any services like Rackspace.

In the end it comes down to asking Rackspace what to do,..not Experts-exchange.  They are the ones that you have to work out a solution with.  They are the solution provider,...they should be providing you with a solution that works,...its their job.

Thanks for your help. I will continue to work with them to attempt to get the routing working, I will leave the question open for now until I get a solution.