magarity
asked on
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
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
ASKER
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
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
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Simple. Turn on logging for all chains (-l) and check your logs to see which one is blocking dhcp.
-Jon
-Jon
ASKER
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
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
"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
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
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