DHCP responding to en0, even though it's set to en1.

Question

I'm a contractor to a school's music department. I installed a Leopard server six months ago. AFP, DHCP, DNS, OD, SUS, Home Folders... en0 connected to the school's network allowing SUS to populate, and DHCP serving en1 to a classroom. Everything has been fine.
A teacher asked me to provide internet access to the classroom, so I ran the Gateway Setup Assistant. This, apparently, turns on NAT and Firewall, and changes some DHCP settings (which I had to put back). Anyway, internet was working in the classroom.
I realised that turning the Firewall off stops internet in the classroom, which I mentioned to the teacher and he began using this (rightly or wrongly) as a way to allow only some lessons access to the internet.
But a week later, the whole school's network began to grind to a halt. DNS queries timing out, and ping raising to over 500. Some stern looking technicians visited and asked for my server to be disconnected from the school's network. The school's network began working again. Feeling naughty, I connected it again, only for them to come back and tell me off.
My server is in the dog house.
It's a gradual worsening of network performance when my server is connected, and a gradual improvement when I disconnect it.
I've looked in the DHCP log and I was surprised to see lots of mentions of en0, with the names of computers on the school's network (as well as my classroom network). One in particular was listed hundreds of times in a row, making requests 30 or 40 times a second. This kind of network activity might just tally with the symptoms.
My questions are: Should I see these mentions of computers on en0, even though DHCP is clearly set to en1? Has the Gateway Setup Assistant caused a problem? What role might the firewall play in this (I've left the firewall rules set as the GSA left it).
Can anyone offer a suggestion for me to fix it?

Answer 1

I have the same problem here. Quad-Xeon Xserve is always listening and answering DHCP requests on both (en0 and en1) interfaces resulting in clients never receiving an IP and permanent loss of network connectivity due to IP address conflicts.
I've seen this issue since 10.5.0 and have never been able to really fix it, Apple denies that the problem exists.
I've filed this under Apple Radar Bug ID # 6946763
I have no way of working around this since we're using OD, networked homes and iCal Server which all depend on DHCP parameters not available on other DHCP servers. (eg. if I would use a linux machine just for DHCP.)
This usually looks like this in the system.log
Jun 4 14:09:15 gate bootpd[82816]: DHCP DISCOVER [en1]: 1,0:24:36:ef:28:8b
Jun 4 14:09:15 gate bootpd[82816]: replying to 192.168.150.32
Jun 4 14:09:15 gate bootpd[82816]: OFFER sent <no hostname> 192.168.150.32 pktsize 359
Jun 4 14:09:15 gate bootpd[82816]: service time 0.000644 seconds
Jun 4 14:09:15 gate bootpd[82816]: DHCP DISCOVER [en0]: 1,0:24:36:ef:28:8b
Jun 4 14:09:15 gate bootpd[82816]: replying to 192.168.150.32
Jun 4 14:09:15 gate bootpd[82816]: OFFER sent <no hostname> 192.168.150.32 pktsize 359
Jun 4 14:09:15 gate bootpd[82816]: service time 0.000470 seconds
Jun 4 14:09:16 gate bootpd[82816]: DHCP REQUEST [en1]: 1,0:24:36:ef:28:8b
Jun 4 14:09:16 gate bootpd[82816]: replying to 192.168.150.32
Jun 4 14:09:16 gate bootpd[82816]: ACK sent <no hostname> 192.168.150.32 pktsize 359
Jun 4 14:09:16 gate bootpd[82816]: service time 0.001276 seconds
Jun 4 14:09:16 gate bootpd[82816]: DHCP REQUEST [en0]: 1,0:24:36:ef:28:8b
Jun 4 14:09:16 gate bootpd[82816]: service time 0.000784 seconds
Jun 4 14:09:16 gate bootpd[82816]: DHCP DECLINE [en1]: 1,0:24:36:ef:28:8b
Jun 4 14:09:16 gate bootpd[82816]: service time 0.000188 seconds
Jun 4 14:09:16 gate bootpd[82816]: DHCP DECLINE [en0]: 1,0:24:36:ef:28:8b
Jun 4 14:09:16 gate bootpd[82816]: dhcpd: host 1,0:24:36:ef:28:8b declines IP 192.168.150.32 from server 192.168.150.7
Jun 4 14:09:16 gate bootpd[82816]: service time 0.000233 seconds
Trying to remedy by static MAC bindings does not help. Deleting and setting up again DHCP config doesn't help either.
Any ideas on what I could test is appreciated. I can provide any details you might need. (Logs, configs, etc.)
Best regards
MacLemon