I have a windows SBS 2008 box running as DC/DNS/DHCP/Exchange/File Server to a network on 192.168.1.0/24. Suffice it to say that the IP of the SBS box is immutable. At some point in the past my predecessor here attempted to get 2 NICs running with 2 IPs on it (which is so very unsupported) and since then, attempting to change any of the network properties causes it to bluescreen on the prompted-for restart - we have had to restore from snapshots when this happens, there doesn't seem to be a way around it.
We have recently started a project to get rid of SBS and build a real 2008/2012 (tbd) domain with 2 DCs, a seperate VM for Exchange, one for fileshares etc etc (yay!) but the prerequisite is that we transition to a new IP Scope (we will be getting onto a VPN with Head Office, allowing us to offload many of these services onto their network).
This leaves me in kind of a sticky situation - I need to get the routers, workstations, terminals... pretty much everything on the network EXCEPT DC/DNS/DHCP/Exchange/File server onto a different scope, while maintaining connection to those services running on SBS which has to stay on 192.168.1.0/24 .
One further complication on the issue is - we have 2 gateways here. One is used by SBS, the other... pretty much everything else - This is to allow SMTP and HTTPS traffic from outside to hit it.
OK so here is what I plan to do - I have set up a VM with a minimal install of Ubuntu 12.04 and a NIC on each network scope. It has static routes set up to reach each network on it's respective interface, and I plan to push out another route via DHCP allowing client on the different scopes to contact each other by routing through the linux box.
So for example I have routes:
Client at 10.0.0.20
destination 192.168.1.0 mask 255.255.255.0 gateway 10.0.0.10 interface 10.0.0.20
Linux Router at 10.0.0.10 & 192.168.1.10
destination 192.168.1.0 mask 255.255.255.0 gateway 0.0.0.0 interface 192.168.1.10
destination 10.0.0.0 mask 255.255.255.0 gateway 0.0.0.0 interface 10.0.0.10
DC at 192.168.1.200
destination 10.0.0.0 mask 255.255.255.0 gateway 192.168.1.10 interface 192.168.1.200
At the same time I will move the internet gateway currently being used by everyone (not the one set up for DC) to the 10.0.0.0/24 network, so the 10.0.0.0/24 clients have a default gateway in their scope and the 192.168.1.0/24 clients (just the DC really) have a default gateway in it's scope (at this point the only remaining things in the 192.168.1.0/24 network are the DC and it's gateway).
Yes I am getting around to asking something! I want to confirm whether the DC can serve DHCP to these clients while being in a different scope. Research has led me here, which seems to suggest it is not possible without a DHCP Relay server in one case (Assuming I am correctly parsing a "network segment" as fairly analogous to a subnet), but also mentions Super Scope, which sounds like it MIGHT answer the issue (as it assigns address to any devices outside the other scopes... I think).
It seems to me that when a client is requesting an address it doesn't yet have an address anyway, so how can it determine whether it is in the same "network segment" as the DC anyway?
To clarify in a TL;DR kind of format - Can I serve 10.0.0.0/24 addresses as well as other network properties like static routes, DNS and default gateways to clients from a DHCP server sitting at 192.168.1.200/24 ? Do I need to use a Superscope to do so?
Also if you see any other problems with my plan, please don't keep quiet!
using the DHCP-helper tool suggested by @HopelessN00b I was able to get this actioned fairly smoothly! A few things were problematic -
- The clients are all in the same network segment, there is no need to go through a layer 3 switch to reach the DHCP server. This resulted in all my clients grabbing 192 addresses because they were communicating directly to the server. I wanted to keep the 192 scope listed because a) if I had gotten in this morning to discovered I had screwed up, it would be easy to rollback; and b) As a handy listing of those services still on the 192 subnet; but I was able to get around this dodgily by creating an exclusion range for the scope that matched the full range of scoped addresses (ie, the scope went from 192.168.1.20 to 192.168.1.200, I created an exclusion range from 192.168.1.20 - 192.168.1.200). It makes me feel a little dirty, but it works, and the 192 subnet only needs to survive a few weeks for us to migrate services.
- There were a few devices which I discovered this morning do not support receiving a static route through the DHCP option 121 (namely: WYSE terminals). They were happily taking 10.61.73.x addresses but had no way to route to terminal server on 192.168.1.x. As the terminal server itself happily took the routes, I set them up statically in the 192 subnet for now, which has resolved their issues.
@us10610 wanted to know the config I used on linux for DHCP-Helper - it was scarily simple -
/etc/default/dhcp-helper contains a single line I modified from default:
eth1 being the NIC that shares a subnet with the DHCP server. It then happily accepted DHCP UDP from it's other NIC and broadcast them on