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.
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 184.108.40.206+) 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.
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...
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?
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 192.168.2.0/24 subnet hardcoded by an Internet Sharing configuration file, I found this helpful KB article:
citied in this interesting discussion: