mac os x server and dhcp

When a computer send out an DHCP request it grabs the first device that answers.

So some times your TC answers first and sometimes it could be the DHCP in OS X.

Use one device as DHCP-server and the other device to DHCP-relay to the server. 🙂

Bridge-mode. But then you disable NAT as well.

Do you have a router in front of the TC?

Why dont you want the TC to manage the DHCP?

After a little googleling i found that the TC blocks DHCP offers from other DHCP-servers.

So devices connected to the TC will never get a DHCP offers from the OS X server if you dont put the TC i bridge mode.

But then it wouldn't be much of router because bridge-mode also disables NAT.

That's not entirely true. You can set the TC to handle DHCP requests for just the first couple addresses (I use the server and my primary desktop), then set the server to handle the rest. Here's a good video for how to set that up: http://youtu.be/qyU4vpMljEI. I do that because Mac OS Server is better at handling static DHCP settings but I don't want to turn off the NAT.

Certainly try dedicating a DHCP pool of one IP address to a MAC address, as was described in that video. I might go as far as dedicating that IP address to a MAC address that doesn't exist on the network, as the local servers and static-addressed devices are intentionally not dependent on any DHCP requests; they're entirely static-addressed. I haven't tried this, as I don't use the particular configuration described in the video, as I prefer to avoid using the Airport or a Time Capsule as a firewall gateway router; I have and use and recommend a dedicated gateway firewall router. I also prefer to configure the Apple wireless devices as access points (what Apple refers to as bridge mode), and not as WiFi routers.

It is possible to run multiple DHCP servers for some cases — for reasons not germane to this discussion, I have three DHCP servers running on one network I deal with — so long as the DHCP server address pools don't overlap with each other or with the static addresses. Ugly, but possible.

If you can't run as an access point (bridged), then having DHCP relay in the device would be preferable. But AFAIK Apple's wireless devices don't support that operation.

My preference is a gateway-firewall device and preferably with VPN server capabilities, running Airport or Time Capsule devices as access points, and having the server or some other device running DHCP.

FWIW, that video somewhat conflates port forwarding and NAT. NAT is the address translation. Port forwarding is how you configure remote requests through that address translation. Also adding the IP address of the DNS server into the box itself as is offered in that video will likely also trigger DNS timeouts when the non-local address is selected. It did, last time I tested that. His description of setting up multiple local and remote DNS servers in the same list is also something I wouldn't recommend, as you don't want your DNS queries potentially going to the remote DNS servers as you won't get the local translations.

pfSense and various other open-source gateway-router software packages are available if you have some spare ARM or x86-class hardware with two network interface controllers, and there are also a number of commercial gateway-firewall product offerings with various features. Since I'm potentially running remote access, having the VPN server in the gateway avoids most of the various "fun" that arises with NAT traversal in a VPN; VPNs and NAT run at cross-purposes.