5 Replies Latest reply: Mar 29, 2012 6:32 PM by John Kassebaum
John Kassebaum Level 1 (5 points)

Why do my DHCP settings automatically reset after changing router addresses in Server Admin/DHCP settings? Happens after upgrading Mac Mini Server to 10.7.3 from 10.6.8 thru the App Store.


Configuration: Comcast modem connected to USB Ethernet on Mac Mini.  Mac Mini built in ethernet connects to switches on LAN. 


Comcast SMC 8014 modem has DHCP turned off and assigned static IP, subnet mask  In SystemPreferences/Network, Mini’s USB ethernet has static IP, subnet mask, router, and Mini’s built-in ethernet static IP, subnet mask, router


Server Admin: DHCP configuration: subnet 1: USB ethernet has subnet through, subnet mask, router, and subnet 2: builtin ethernet hosts range through, subnet mask, router  DNS is OK. 


If I change the router address in Server Admin/DHCP settings, the DHCP settings reset to the same subnet names, but router entries, DNS entries, LDAP entries and WINS entries in DHCP subnets all go away and the subnets reappear disabled, almost as if they’d automatically been re-made.  Re-enabling and restarting DHCP gives a log error of bootp configuration file not found, even though the service operates normally after a reboot.

Mac mini, Mac OS X (10.7.3)
  • Camelot Level 8 (46,665 points)

    I'm somewhat confused about your setup, and I'm guessing BOOTPD is, too.


    Why are you using double-NAT on your network? Your Mac Mini is running NAT, as is your Comcast box.

    Double-NAT is one of the three big evils in IP networking. Avoid it if you can.


    Even if you can't avoid it, why are you running DHCP on both interfaces on the Mac Mini? What else is on the Comcast Router <-> Mac Mini network that needs DHCP?


    Even if you need this second LAN, why do you want the Mac Mini to handle DHCP and not the Comcast box? You're creating a dependency on the Mac Mini that seems pointless, at best.

    So, in all, a more in-depth discussion of your network topology/plans seems worthwhile.

  • John Kassebaum Level 1 (5 points)

    Thanks so much for your response and your help. 


    I'm not too afraid of double nat, I trust the hardware to keep it straight for themselves, though I recognize the redundant effort.


    When I upgraded to OSX Server 10.7.3 , I also installed the Comcast SMC 8014, a forced upgrade due to the older model failing.  Prior to these changes, with the old Comcast box and Snow Leopard Server 10.6.8, the basic configuration I described worked fine for years: DCHP on OS X Server LAN on built in etherhet, static IP on the Comcast Box and the server NIC on USB Ethernet. The server is the DMZ of the Comcast box.  DNS, VPN, VNC, FTP all worked fine.


    Now after upgrading to OSX Server 10.7.3, when I tried to re-use those settings, Server Admin/DHCP freaks out. Even if I run Gateway Setup Assistant, I get a DHCP subnet for built in ethernet, but the router address in the DHCP settings is blank. Putting one in manually causes bootpd to freak, my subnet disappears and is replaced by two new ones: one for the LAN ('192.168.2 Ethernet') and one for the WAN ('192.168.1 USB Ethernet').  Both are disabled and the DHCP service is off.  I have no idea why.  It is because, though, that OS X Server repeatedly insists on putting a DHCP subnet in for the WAN that I left it in.


    If I configure these provided subnets, slowly, saving after every change, restart the service and then reboot, the system, LAN, and WAN access is stable.  Both Mac and Windows clients get IPs and surf and share happily. But VPN clients (addresses in range cannot ping anything but the two server NICs and the Comcast box.


    I do not want the comcast box routing the network, so I've never used it as a DHCP server.  The OS X Server runs a VPN, and performs NAT to facilitate VNC and FTP.  The Comcast Box can't do all that, particularly reserving IPs and assigning IPs to VPN clients.


    Any thoughts would be IMMENSELY appreciated.

  • Brettermeier Level 1 (25 points)

    There seems to be a problem with server admin writing his config file when DHCP, DNS and NAT is activated. Every time dhcp server lost his configuration there is a message in system.log(?) that tells you that the bootp config file is corrupt and therefore it will be recreated by server admin. I got this issue too and completely gave up try to solve that because the 192.168.2/24 subnet is hard coded into the file /usr/libexec/InternetSharing and i dont want to use that subnet. What a nice programmed nat/router, that tells you which subnet you have to use...

  • Steve_eo Level 1 (0 points)

    I can confirm that I'm seeing similar behaviour.

    What is worse still is that I also see my en0 interface coming up in the dhcp subnet window as well. Even if I delete that interface (en0).....which is of course my WAN side, it will somehow majically reappear. I can't seem to narrow it down to when or how this happens. But certainly there is at least one other process that is invisible to me that is creating subnets in on the dhcp server.

    Anyone got a clue what the process is? Can we kill it off somehow so that Server Admin is actually in charge of setting the subnets?

  • John Kassebaum Level 1 (5 points)

    I've since discovered that if the NAT service is active when you restart the DHCP service, the dhcp configuration file is blown away because the existing file is not accessible for writing by bootpd as NAT owns it.  So bootpd presumes the file does not exist and creates a new one based on what I'm not sure, though the subnets it creates appears to be influenced by network interface configurations in System Prefs.  Disabling NAT when modifying DHCP settings in Server Admin is the fix.  I now strictly follow this activation (and reverse deactivation) chain: Firewall, DNS, DHCP, NAT, then any other service.  Before I modify and restart any service, I deactivate all services higher in the chain.


    As to using an alternate to the subnet hardcoded by an Internet Sharing configuration file, I found this helpful KB article:



    citied in this interesting discussion: