Reserved IP Ranges

Question

Reserved IP Ranges

I cannot find anything which matches this exactly, so I apologize if I am duplicating.

I am trying to set up two different ranges of IP addresses on a 10.4.11 server so that Group A would derive an IP from a 10.X.X.X range, while Group B would pull from 10.Y.Y.Y. It sounds simple enough, but in practice - not so much.

I have configured the Server Admin app with the two different valid subnet ranges, as outlined above. All the documentation from Apple I can dig up swears if you deselect 'Enable' in the DHCP section, no computer will pull an IP address from that subnet. In practice, however, every single computer pulls IP addresses from the 10.X.X.X range even though it is not checked enabled !

The idea was to have the 10.X.X.X range all be assigned static, and 10.Y.Y.Y range be DHCP. Too bad the computers didn't get the memo because they are all pulling from the 10.X.X.X range until depleted, THEN they start on the 10.Y.Y.Y range. It seems no configuration I enter changes this fact.

Does anyone have a bone to toss me? We are talking a couple hundred computers here and I would rather not have to static the entire mess.

Thank you in advance !

iMac, Mac OS X (10.6.2)

Posted on Feb 11, 2010 9:28 AM

Reply

Answer 1

Camelot

Level 9

58,527 points

Feb 11, 2010 11:35 AM in response to Buster Blocker

I'm not entirely sure I understand the issue.

From what I think you're saying, you want the DHCP server to hand out addresses in the 10.Y.Y.Y pool and not from the 10.x.x.x pool, right?

If that's the case, why bother defining the 10.x.x.x pool at all?

from your description it sounds like you're saying the 10.x.x.x pool is used even though it's not enabled - and that might be a bug, but the simple solution would be to remove it altogether, no? That way there's no way the DHCP server will hand out those addresses, enabled or not.

Am I missing something?

Reply

Answer 2

Feb 11, 2010 12:28 PM in response to Camelot

Thank you for the rapid response.

I don't think you are missing anything, per se. It is being done for reasons of security.

In other words, members of Group A will have static 10.X.X.X addresses and therefore will have not have certain internet filters applied based on the IP. Conversely, those pulling from the DHCP (Group B) will have more restrictions based on pulling IPs from the 10.Y.Y.Y range.

That is why there has to be two subnets for the network. I hear you on your solution, but for the task I have been set it isn't a option. The filtering is being done on the basis of IP and there is no other way to do it, either from a monetary or bureaucratic standpoint.

Reply

Answer 3

Camelot

Level 9

58,527 points

Feb 11, 2010 2:31 PM in response to Buster Blocker

No, you still don't understand what I'm saying.

members of Group A will have static 10.X.X.X addresses

OK, I get that. These machines have static IPs

I hear you on your solution, but for the task I have been set it isn't a option.

Why not? If you're setting the Group A machines manually then why do you need the DHCP server to ever come close to thinking about them? It doesn't need them, or need to know anything about them.

Reply

Answer 4

Feb 11, 2010 4:56 PM in response to Camelot

Camelot wrote:
No, you still don't understand what I'm saying.

That may be true.

OK, I get that. These machines have static IPs

Which come from the range which is supposedly - according to Apple's documentation - never, ever supposed to be handed out by the DHCP server. But in reality still is.

Why not? If you're setting the Group A machines manually then why do you need the DHCP server to
ever come close to thinking about them? It doesn't need them, or need to know anything
about them.

And here is where we part company, so to speak.

Precisely how will this specific range of IPs never see the light of day if they are not reserved? I know in practical application they are not reserved, which is why I am hoping to find out how to stop this. How do I stop anything on the network from using that range when - as an example - I have 10.50.1.X through 10.50.10.X powering the entire network and I just need 10.50.5.X for Group A alone?

Sure, I wipe 10.50.5.X out on the OS X Server, and DHCP doesn't specifically hand out those numbers, but it doesn't mean they aren't still valid. Even leaving one range open means 255 potential security holes. I need the DHCP server to block anything using a non-static address in that range from working.

I don't know how better I can explain it than this.

The only solution I can come up with is limiting the reserved range to exactly the number of computers that need to have better access, and shoving the rest on to the next available, more secure range. But I shouldn't have to do this - the software should just work as the documentation indicates it should. In a perfect world, that is. 😉

Reply

Answer 5

Camelot

Level 9

58,527 points

Feb 11, 2010 5:24 PM in response to Buster Blocker

need the DHCP server to block anything using a non-static address in that range from working.

OK, now I get it. You're looking in completely the wrong place.

The DHCP server is never going to do this for you. That's not its role.

For any given subnet, any IP address within the subnet range is valid. End of story. It doesn't matter whether any host system is configured via DHCP or statically, if it's within the subnet, it's valid. Furthermore, just because the DHCP server is configured to hand out a range of addresses within the subnet, there is nothing within the DHCP standard to prevent hosts taking another IP address within the subnet. The DHCP server doesn't even come into question.

For example, given the range 10.1.1.0 through 10.1.1.255, you may configure the DHCP server to handle 10.1.1.101 through 10.1.1.200. That's great, and you can be assured that DHCP clients would get an address in that range. However, it is perfectly valid for a host system to be configured with another address within the subnet but outside of the DHCP range - e.g. 10.1.1.56 would be valid, even though it's not in the DHCP range. The DHCP server cannot prevent this.

If you really need to lock down your network at that level then you need to be looking more towards something like 802.1X - port based authentication - which is a protocol that runs within the switch and determines what IP addresses are valid for each port on the switch. In this way you can force specific ports on the switch to be within a certain range (e.g. DHCP clients, 'secure' systems, etc.) and that's about the only way you can prevent someone from configuring a machine with an IP address in the subnet but outside of the DHCP pool.

I don't believe there's anything in the Apple Server documentation that is contrary to what I'm saying here. It's standard IP networking stuff.

Reply

Answer 6

MrHoffman

Level 10

146,233 points

Feb 11, 2010 6:05 PM in response to Buster Blocker

A DHCP server provides IP addresses to clients that ask for an address, either openly, based on MAC, or based on authentication. Beyond maintaining and accounting for IP addresses marked as free and as allocated within its assigned address pool, DHCP is not an enforcement mechanism for a subnet.

Some of the usual approaches here are to authenticate onto the network via RADIUS or such (either via WiFi or via a managed switch or such), or to leave the network open to access but with restricted or no connections to other networks and to require clients to VPN into the trusted part(s) of the network. The former is an option in a controlled network, and the latter is analogous to how (trusted, remote) connections can arrive onto your LAN via the Internet.

Reply

Answer 7

Feb 12, 2010 7:30 AM in response to MrHoffman

MrHoffman wrote:
A DHCP server provides IP addresses to clients that ask for an address,
either openly, based on MAC, or based on authentication.

Ok, and here is the rub : if 10.4.X server was capable of doing a true reserved range nothing on the network should be able to use that IP address. It should hit the server, and the server deny a network connection based on the rules in the DHCP server. That's the whole point of having a _reserved range_. Again, I realize this is a perfect world I am talking about.

That being said, I tried shutting down (ok, removing) the entire range from the server and nothing happened. I mean nothing happened on the clients. They retained the exact same IP they had yesterday; this despite the fact I shortened the lease time to two hours a few weeks ago, and according the the DHCP service there is no computer on my network with a lease of longer than two hours. Even manually refreshing the DHCP on the Mac OS X clients does nothing.

Let me emphasize : _these are not the computers with static addresses_. The computers with static addresses took their changes immediately.

So I am left with one of two things to believe : either DHCP in OS X.4.11 Server is completely farked, and crapware of the first order, or the OS X client software really doesn't heed the DHCP server; meaning I am completely farked, and OS X client is crapware of the first order where DHCP is concerned.

As always, I am enthusiastic to hear differing opinions. And I am grateful beyond measure for the input! I humbly thank you.

Reply

Answer 8

MrHoffman

Level 10

146,233 points

Feb 12, 2010 8:03 AM in response to Buster Blocker

So where do the clients get their DHCP addresses from?

I've certainly ended up with the occasional DHCP rogue server around, and I have networks where I deliberately run multiple DHCP servers (with non-overlapping address pools) in the subnet.

The following lists the interfaces present on the particular box (and a list which can vary), then tries en0 (no response; not DHCP) and then en1 (which does have a DHCP packet) (this as the en-class devices are usually the Ethernet-style networks), and shows the IP address of the DHCP server that assigned the address from its pool in the second of the two ipconfig commands.

+$ ifconfig -l+
+lo0 gif0 stf0 en0 fw0 en1+
+$ ipconfig getpacket en0+
+$ ipconfig getpacket en1+
+... some stuff ...+
+server_identifier (ip): 10.11.12.13+
+... more stuff ...+
+$+

Confirm that the server_identifier is the expected DHCP server host address.

It could well be stuffed. Or there could be other issues with the LAN or LAN configuration. I really don't know. I don't have a handy Tiger Server available for testing, and I do remember encountering a few DHCP weirdnesses back then.

Reply

Answer 9

Feb 12, 2010 8:54 AM in response to MrHoffman

MrHoffman wrote:
So where do the clients get their DHCP addresses from?

Where?

_From the Mac OS 10.4.11 server, of course_.

It looks like the DHCP Server in Tiger Server really is crapware. Apparently, stop doesn't really mean stop. Just like a Win server, if you make any DHCP changes you must _restart the entire server, not just the Service_.

Once the server was restarted everything clicked. So, the ultimate solution was decided to be :

1. Just remove the octet to be static from the DHCP server (thanks, Camelot!).

2. Make all the changes to the DHCP Service you are are going to make.

3. _Restart the entire Mac OS 10.4.11 server_.

4. Then - and only then - does the server stop handing out IPs based on the octet you wish taken out of the DHCP loop for use as static IP addresses.

Then again, I believe the little button that says STOP really should stop the service, so what do I know? 😉

Thanks again for the great pointers, and the time you both put in to come up with answers. I deeply appreciate your efforts.

Reply

Answer 10

Feb 12, 2010 8:56 AM in response to Buster Blocker

To have "reserved" ranges for static IPs in Mac OS 10.4.11. Server, just do not enter the octet as a subnet in the DHCP service. Enter all the Static Mapping, then RESTART THE ENTIRE SERVER, NOT JUST THE DHCP SERVICE.

Reply