Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

On my other thread I was talking about some interesting things about the iptables policy and states, now I would like to understand more about how the DHCP works and how iptables understands it.

ETH0 is connected to my main switch that receives the dynamic ip from my router to gain not only internet access but aswell as access to my outer network.

ETH1 is the internal card that is connected to a internal switch where X clients receive their IPS from this server

ETH1 network is 192.168.1.0/255.255.255.0 where the server ip is 192.168.1.254.

From what I understood, dhcp is a bootp protocol so even if you have your firewall policies to DROP everything, your network would still receive the DHCP, which in the tests I made it seemed to be true.

From tcpdump:

root@test:~# tcpdump -i eth1 port 67 or 68
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 96 bytes
11:34:03.943928 IP 192.168.1.2.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:0c:29:29:52:8b (oui Unknown), length 303
11:34:03.957647 IP 192.168.1.254.bootps > 192.168.1.2.bootpc: BOOTP/DHCP, Reply, length 300
11:34:06.492153 IP 192.168.1.2.bootpc > 192.168.1.254.bootps: BOOTP/DHCP, Request from 00:0c:29:29:52:8b (oui Unknown), length 303
11:34:06.506593 IP 192.168.1.254.bootps > 192.168.1.2.bootpc: BOOTP/DHCP, Reply, length 300

I made a simple log rule to see what iptables does:

root@test:~# tail -f /var/log/syslog
Oct 15 11:30:58 test kernel: IN=eth1 OUT= MAC=ff:ff:ff:ff:ff:ff:00:0c:29:29:52:8b:08:00 SRC=192.168.1.2 DST=255.255.255.255 LEN=331 TOS=0x00 PREC=0x00 TTL=128 ID=9527 PROTO=UDP SPT=68 DPT=67 LEN=311
Oct 15 11:31:43 test kernel: IN=eth1 OUT= MAC=ff:ff:ff:ff:ff:ff:00:0c:29:29:52:8b:08:00 SRC=192.168.1.2 DST=255.255.255.255 LEN=331 TOS=0x00 PREC=0x00 TTL=128 ID=9529 PROTO=UDP SPT=68 DPT=67 LEN=311
Oct 15 11:33:32 test kernel: IN=eth1 OUT= MAC=ff:ff:ff:ff:ff:ff:00:0c:29:29:52:8b:08:00 SRC=192.168.1.2 DST=255.255.255.255 LEN=331 TOS=0x00 PREC=0x00 TTL=128 ID=9531 PROTO=UDP SPT=68 DPT=67 LEN=311
Oct 15 11:34:03 test kernel: IN=eth1 OUT= MAC=ff:ff:ff:ff:ff:ff:00:0c:29:29:52:8b:08:00 SRC=192.168.1.2 DST=255.255.255.255 LEN=331 TOS=0x00 PREC=0x00 TTL=128 ID=9533 PROTO=UDP SPT=68 DPT=67 LEN=311

Here is my iptables rules at the momment:

# deny all traffic
$IPT -P INPUT DROP
$IPT -P FORWARD DROP
$IPT -P OUTPUT DROP

# Use stateful inspection feature to only allow incoming connections
# related to connections I have already established myself
$IPT -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
$IPT -A OUTPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

# allow all traffic on lo interface
$IPT -A INPUT -i lo -j ACCEPT
$IPT -A OUTPUT -o lo -j ACCEPT

So even with the default POLICY to drop everything i still get the DHCP on my network while it does take a lot longer to renew an IP and such.

If I add the follow rule to my firewall:

$IPT -I OUTPUT -o $INTIF -p udp --dport 67:68 --sport 67:68 -j ACCEPT

It will take a LOT LESS TIME to update any client dhcp.

Considering the above:

  1. why does it indeed take longer time to update it even tought it is not being blocked ?
  2. is it possible to DROP the dhcp server at all without turning it off ?
  3. is it possible to ACCEPT the dhcp server within iptables with the BOOTP ? how is that done ?

If you know good links I wouldn't mind taking a lot :)

share|improve this question
    
I'm a bit confused by your tcpdump and iptables log output. Are you monitoring the network interface in promiscuous mode? Is your firewalled server actually using DHCP to configure its NIC? –  Steven Monday Oct 15 '10 at 15:51
    
@Steven the server that has the firewall which is the one mentioned above has eth0 and eth1, eth0 receives dhcp as a client from the outside and eth1 is my dhcp server for my internal network which is the one i am talking about. What do u mean by Are you monitoring the network interface in promiscuous mode i am still learning... –  Guapo Oct 15 '10 at 15:54
    
Oh, ok. You really need to better describe your network and servers if you want anyone to understand your question! –  Steven Monday Oct 15 '10 at 16:01
    
About promiscous mode: en.wikipedia.org/wiki/Promiscuous_mode –  Steven Monday Oct 15 '10 at 16:02
    
@Steven will do that now thanks for point out, do you think i have to specify anything else other then the network layout ? –  Guapo Oct 15 '10 at 16:17

2 Answers 2

up vote 4 down vote accepted

I'll answer #2: No.

When getting an IP address the dhcp daemon creates a raw socket to the network interface and handles the UDP protocol itself. Thus the UDP packets never go through iptables.

The reason the dhcp daemon has to implement UDP is that the kernel can only handle UDP (in fact all of the TCP/IP suite) when the interface has an IP address. Previously dhcp daemons would first give an interface the IP address of 0.0.0.0 but that no longer works.

share|improve this answer

Adding

$IPT -I INPUT -i $INTIF -p udp --dport 67:68 --sport 67:68 -j ACCEPT

shall make DHCPD update faster :) It shall works both side INPUT and OUTPUT. You can DROP dhcpd with ebtables, not with iptables. DHCPD listening at 0.0.0.0, not within IP

share|improve this answer
    
+1 I had it on INPUT and it was taking the same amount of time as if I didnt had it on my rules. When I made it OUTPUT it did make a HUGE difference. I will read about ebtables thanks. –  Guapo Oct 15 '10 at 16:27
    
$IPT -I INPUT -i $INTIF -s 0/0 -p udp --dport 67:68 --sport 67:68 -j ACCEPT –  Ta Coen Oct 15 '10 at 16:41
    
just tried the above and still taking too long compared to using the OUTPUT rule. –  Guapo Oct 15 '10 at 16:45
    
Since the policy is DROP, then you shall use both INPUT and OUTPUT. –  Ta Coen Oct 15 '10 at 16:55

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.