• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 961
  • Last Modified:

iptables vs dhcpd

I've set up a NAT firewall for a cable modem.  All works perfectly for the two machines behind the wall.  To make it easier to take a laptop to other places that use dhcp, I set up dhcpd on the firewall box.  Unfortunately, no addresses ever show up at the Win98 laptop.

Watching dhcpd on console (dhcpd -r -f eth1) reveals that the requests never show up.

Something in the firewall script is killing the incoming dhcp requests because if I comment out rc.firewall in rc.local the dhcp works perfectly.  I've searched google for other people doing the same thing, but can only find people using ipchains.

Can anyone supply a specific iptables line that would allow incoming dhcp requests only on eth1?

Digging through the iptables man page, the best I make on my own was:

iptables -A udpincoming_packets -p UDP -i eth1 --source-port 67 -j ACCEPT

...since I thought that dhcp requests were upd type on port 67, but that doesn't work.

thanks for any help!
magarity
0
magarity
Asked:
magarity
1 Solution
 
superschlonzCommented:
DHCP clienst send packets from ip 0.0.0.0 port 68 to 255.255.255.255 port 67. I'm not sure if the answer from the server comes from 255.255.255.255 or its real ip.
So if you filter the packets bi IP that go to the chain udpincoming_packets it will not work.

You could try to set it up this way:

# all udp packets to chain udpincoming_packets
iptables -A input -p udp -j udpincoming_packets
# accept DHCP packets from IP 0.0.0.0
iptables -A udpincoming_packets -p udp \
  --source 0.0.0.0 --sport 68 \
  --destination 255.255.255.255 --dport 67 \
  -i eth1 -j ACCEPT
# accept DHCP packets from our network
iptables -A udpincoming_packets -p udp \
  --source 192.168.1.0/24 --sport 68 \
  --destination 192.168.2.1 --dport 67 \
  -i eth1 -j ACCEPT

Ofcourse you could do it a bit simpler:

iptables -A udpincoming_packets -p UDP -i eth1 --source-port 68 -j ACCEPT
0
 
magarityAuthor Commented:
super,
That looked promising, but didn't work.  dhcpd never reported any requests showing up.

Local network is 192.168.0.x with the linux box being 192.168.0.1.  I tried a variety of modifying the second set of IPs you listed above...  I assume I should use "--source 192.168.0.0/24" and "--destination 192.168.0.1" or is that wrong?

Thanks
magarity
0
 
ifinchamCommented:
Hi,

Not certain on this but try these for size...

/sbin/iptables -t nat -A PREROUTING -i eth1 -p UDP -s 192.168.0.1 --sport 68 --dport 67 -j ACCEPT

/sbin/iptables -A OUTPUT -o eth1 -p UDP -s 0.0.0.0/32 --sport 67 -d 255.255.255.255/32 --dport 68 -m state --state ESTABLISHED -j ACCEPT

/sbin/iptables -A INPUT  -i eth1 -p UDP -s 0.0.0.0/32 --sport 68 -d 255.255.255.255/32 --dport 67 -m state --state NEW,ESTABLISHED -j ACCEPT

/sbin/iptables -A OUTPUT -o eth1 -p UDP -s any/0--sport 67 -d 192.168.0.1 --dport 68 -m state --state ESTABLISHED -j ACCEPT

/sbin/iptables -A INPUT  -i eth1 -p UDP -s 192.168.0.1 --sport 68 -d any/0 --dport 67 -m state --state NEW,ESTABLISHED -j ACCEPT

Rgds






0
Cloud Class® Course: Microsoft Azure 2017

Azure has a changed a lot since it was originally introduce by adding new services and features. Do you know everything you need to about Azure? This course will teach you about the Azure App Service, monitoring and application insights, DevOps, and Team Services.

 
The--CaptainCommented:
Simple.  Turn on logging for all chains (-l) and check your logs to see which one is blocking dhcp.

-Jon

0
 
magarityAuthor Commented:
infincham,
Those lines made it work, thanks!


Captain,
That would be the first rule that doesn't allow anything.  It's subsequent rules that change iptable's mind and let it accept a packet.

thanks all,
magarity
0
 
The--CaptainCommented:
"That would be the first rule that doesn't allow anything.  It's subsequent rules that change iptable's mind and let it accept a packet."

That is incorrect.  The linux kernel proceeds sequentially through each rule until it is finally redirected to a final result (usually using the -j argument).  The code never 'changes it's mind' - once it gets a final destination for the packet (usually ACCEPT/REJECT/DENY/etc), the ruleset is finished with the packet - no chance for any change of mind later...

This is why the tool used to be called ipchains (it is a reference to the 'chainlike' iteration through the rules), although I guess they felt it needed re-naming once so much additional functionality was added.

I guess I shouldn't have assumed you'd realize that the default policies can be duplicated (and made to log) easily enough with simple rules

-A FORWARD -j DENY -l
-A INPUT -j DENY -l
-A OUTPUT -j DENY -l

etc...  Information generated using the logging option in iptables rules will reveal the problem.

In any case, I'm glad you found your solution.  I'd remember the '-l' trick, if I were you - it _will_ provide the answer to solving most problems like these, or at least tell you why it's not working.

-Jon



0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Cloud Class® Course: MCSA MCSE Windows Server 2012

This course teaches how to install and configure Windows Server 2012 R2.  It is the first step on your path to becoming a Microsoft Certified Solutions Expert (MCSE).

Tackle projects and never again get stuck behind a technical roadblock.
Join Now