Don't know if it's still of interest after such a long time. The point here however is to let the packet OUT not in. Does one need dhclient? If so, one should add a stanza like
Code:
iptables -A OUTPUT -p udp --sport 1024:65535 --dport 67 -j ACCEPT
iptables -A OUTPUT -p udp --sport 68 --dport 67 -j ACCEPT
Of course this has to be root¹). And if netfilter is compiled as modules add -m <proto>, too.
Rationale: dhclient (or similar agent) is configured to renew a dhcp lease, alas iptables doesn't let her connect to the outside's port 67 -- via which port? The documentation on bootp and dhcp unfortunately is not too clear about ports involved. Basically rfc-951 defines 67 as receiving server port and 68 as receiving client port for bootp, but does not define the originial source port. Hence the first sport stanza above. One could of course check with a tool like tcpdump what actually is going on, or search the source files of dhclient blah blah woof woof... if one had the time and energy.
So far dhclient can send its message out and don't clubber your logfiles anymore, but she won't get an answer (which doesn't necessarily matter AFAIK).
If you need the full DHCP thing you would of course have to open up the ports back inside to your box like so:
Code:
iptables -A INPUT -p udp --sport 67 --dport 68 -j ACCEPT
iptables -A INPUT -p udp --sport 1024:65535 --dport 68 -j ACCEPT
Again, the rfc does not define the answering server port.
And remember, if an error turns up in linux log files with "Operation not permitted" it is most often due to the packet filter.
Brgds, e.
¹) Possibly you could add -p tcp, as /etc/services claims the bootp ports for both protocols, even though due to the nature of the dhcp protocol tcp should be irrelevant.