Two DHCP Servers, Block Clients for one of them?

I am building out a kickstart network that resides on a different VLAN uses its own DHCP server. For some reason, my kickstart clients kept getting assign IPs from my primary DHCP server.

The way I have it set up is that I have a primary DHCP server on this router here:

192.168.15.1

Connected to that DHCP server is a switch with the IP of 192.168.15.2. My kickstart (Scientific Linux) server is connected to that switch on two ports:

Port 2 - where the kickstart server communicates to the rest of the production network via eth0. The IP assigned to the server on that interface is 192.168.15.100 (on eth0). The details are:

Interface: eth0
IP: 192.168.15.100
Netmask: 255.255.255.0
Gateway: 192.168.15.1

Port 7 - has it's own VLAN ID (along with port 8). The kickstart server is connected to that port with the IP of 172.16.15.100 (on eth1). Again, the details are:

Interface: eth1
IP: 172.16.15.100
Netmask: 255.255.255.0
Gateway: none

The kickstart server runs its own DHCP server and assigns them over the eth1. Most of the kick starts are built over the kickstart VLAN through port 8. To prevent the kickstart DHCP server from assigning addresses over the production network, I have the route setup like so:

route add -host 255.255.255.255 dev eth1

At this point, the clients kept getting assign IPs from the 192.168.15.1 DHCP server. I need to figure out a way to block client requests from reaching that DHCP. Its should be noted that but I also build KVM hosts on the kickstart server as well, so I need those KVMs to have the ability to get DHCP requests from the 192.168.15.1 DHCP server via the bridge network once I finish resolved this particular problem. (Currently, they communicate via NAT).

So what would be done to resolve this? Through iptables or some sort of routing I need to put in?

I tried to limited to requests via IPtables on that interface, allowing DHCP requests for 172.16.15.x network:

-A INPUT -i eth1 -s 172.16.15.0/24 -p udp -m udp --dport 69 -j ACCEPT
-A INPUT -i eth1 -s 172.16.15.0/24 -p tcp -m tcp --dport 69 -j ACCEPT
-A INPUT -i eth1 -s 172.16.15.0/24 -p udp -m udp --dport 68 -j ACCEPT
-A INPUT -i eth1 -s 172.16.15.0/24 -p tcp -m tcp --dport 68 -j ACCEPT
-A INPUT -i eth1 -s 172.16.15.0/24 -p udp -m udp --dport 67 -j ACCEPT
-A INPUT -i eth1 -s 172.16.15.0/24 -p tcp -m tcp --dport 67 -j ACCEPT

And rejects assignments on eth1 from 192.168.15.x network:

-A FORWARD -o eth1 -s 192.168.15.0/24 -p udp -m udp --dport 69 -j REJECT
-A FORWARD -o eth1 -s 192.168.15.0/24 -p tcp -m tcp --dport 69 -j REJECT
-A FORWARD -o eth1 -s 192.168.15.0/24 -p udp -m udp --dport 68 -j REJECT
-A FORWARD -o eth1 -s 192.168.15.0/24 -p tcp -m tcp --dport 68 -j REJECT
-A FORWARD -o eth1 -s 192.168.15.0/24 -p udp -m udp --dport 67 -j REJECT
-A FORWARD -o eth1 -s 192.168.15.0/24 -p tcp -m tcp --dport 67 -j REJECT

Nope. :(

Solution 1:

Okay, I figured it out - I didn't untag the default vlan, which is causing traffic from default vlan to bleed into my kickstart vlan.

That's been fixed. DHCP assignments do not work anymore on those ports, but least I now know the problem. :)

Solution 2:

I'm glad you solved your VLAN problem, but you might be interested to know that you can use ebtables to filter DHCP traffic.

For example if you have two DHCP servers in two different LANs bridged by device tap0 on a Linux server, you can isolate them and still keep TCP/IP and ARP traffic flowing by running:

modprobe ebtables && modprobe ebtable_filter && modprobe ebt_ip
ebtables -A INPUT --in-interface tap0 \
   --protocol ipv4 --ip-protocol udp --ip-source-port 67:68 -j DROP
ebtables -A INPUT --in-interface tap0 \
   --protocol ipv4 --ip-protocol udp --ip-destination-port 67:68 \
   -j DROP
ebtables -A FORWARD --in-interface tap0 \
   --protocol ipv4 --ip-protocol udp --ip-destination-port 67:68 \
   -j DROP
ebtables -A FORWARD --in-interface tap0 \
   --protocol ipv4 --ip-protocol udp --ip-source-port 67:68 -j DROP

In this example you should run ebtables at both ends so as to not waste bandwidth, but just one would solve the DHCP problem.