Dhcp relay

Материал из noname.com.ua
Перейти к навигацииПерейти к поиску
Gloeiende Oliebollen. I wanted to DHCP relay discovers MSGs off only ‘one’ specific device in my home network somewhere to the DHCP server on the other side of a GRE tunnel. Off course this is not really logical but that’s besides this post.

I installed ISC DHCP “yum install dhcp-4.1.1″. This packages comes with the ISC dhcrelay client which I figured to do the relaying. The Idea was to block all broadcast traffic designed for port 67 on this machine, and only to allow the specific MAC address.

When this was setup, I noticed all the local DHCP discovers/MAC’s passing the filter and thought I made a mistake. I did some troubleshooting and started with blocking individual MAC’s. This is normally an easy task by doing:”-A INPUT -m mac –mac-source 00:02:02:41:d0:77 -j DROP” and checking the hit counter of IPtables.

My Tunnel/VPN Server: IPTV / 10.0.0.253
My test server with relay agent and IPtables MAC filter: centos-test1 / 10.0.0.101

#It get's three hits, It works!:
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
3 1728 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 MAC 00:02:02:41:D0:77

You will think that everything is okay now…. NO it isn’t!

# Still request being picked up and relayed:
[root@centos-test1 ~]# dhcrelay -d -i eth0 10.0.0.253
Internet Systems Consortium DHCP Relay Agent 4.1.1-P1
Copyright 2004-2010 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/
Listening on LPF/eth0/52:54:00:05:b0:a4
Sending on LPF/eth0/52:54:00:05:b0:a4
Sending on Socket/fallback

Forwarded BOOTREQUEST for 00:02:02:41:d0:77 to 10.0.0.253
Forwarded BOOTREQUEST for 00:02:02:41:d0:77 to 10.0.0.253

# And tcpdump output:
21:20:23.596458 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:02:02:41:d0:77, length 548
21:20:23.596597 IP 10.0.0.101.67 > 10.0.0.253.67: BOOTP/DHCP, Request from 00:02:02:41:d0:77, length 548

I spend considerable time figuring this one out. Even thought about a bug in iptables. But it appears that ISC dhcrelay client hooks it-self before the IPtables in the IP stack. It explains why the (DROP) counter is increasing while the packets are being relayed too.

After searching the internet I found:
Per Mark Andrews of isc.org:
"DHCP uses packet filters and these tie into the IP stack before the
firewall."

I decided to go with Kelly’s “DHCP Helper” (wget http://www.thekelleys.org.uk/dhcp-helper/dhcp-helper-1.1.tar.gz), did an make, make install. Fired it up. Added again the line:”IPtables -I INPUT -m mac –mac-source 00:02:02:41:D0:77 -p udp –dport 67 -j DROP” and the problem disappeared:

21:35:23.036248 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:02:02:41:d0:77, length 548
21:35:39.064687 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:02:02:41:d0:77, length 548

Life can be good!