dnsmasq's dhcp blocked to clients by firestarter

[Xeletron]

Binary package hint: firestarter

server: hardy, clients hardy.
In a situation where firestarter is sharing the internet connection and act as a firewall, dnsmasq's dhcp server can not be reached by clients. Shutting down firestarter, all works fine, except the sharing of internet. Enable firstarter again, no dhcp.

The iptables rules decide that all destination traffic to 255.255.255.255 from source 0.0.0.0 (unknown) (even if the port is 67-68) will be dropped. (so no new dhcp requests)

The workaround was to add the following line to /etc/firestarter/user-pre to explicitly allow the DHCP broadcasts early in the INPUT table:

$IPT -A INPUT -i $INIF -p udp -s 0.0.0.0 –sport 68 -d 255.255.255.255 –dport 67 -j ACCEPT
(thanks Andrew)

But i think firestarter should solve this. All new dhcp resolving is done by sending packets to 255.255.255.255 from source 0.0.0.0.

I hope this helps.

Regards. ... ow.. and keep up the good work ;)

[Thierry Carrez (ttx)]

Thanks for reporting this bug and helping in making Ubuntu better.
AFAICT this is not a bug in dnsmasq : if firestarter blocks UDP broadcasts to port 67, that will for sure prevent dnsmasq (or any other DHCP server) to receive and process DHCPDISCOVER / DHCPREQUESTs. So I'll mark this part of the bug invalid.

[Xeletron (xeletron)]

... maybe it's not a bug, but it might be handy to fix this by the install script of dnsmasq if firestarter is detected.

[FactTech (launchpad-facttechnologies)]

I am experiencing a similar issue in intrepid. There does not seem to be a way to set up Firestarter in such a way that DHCP ports are open for services other than dhcpd.

Like ubun2-fan, I am trying to set up dnsmasq, but clients requesting DHCP do not receive any DHCPACK or DHCPOFFER packets in response to their DHCPDISCOVER requests when Firestarter is on. On the DHCP server side, I see lines like this in /var/log/syslog (machine name, MAC addresses, and IP addresses modified from original):

Feb 10 07:44:20 dhcp-server kernel: [38350.566504] Unknown InputIN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:11:22:33:44:55:66:08:00 SRC=0.0.0.0 DST=255.255.255.255 LEN=328 TOS=0x10 PREC=0x00 TTL=64 ID=0 PROTO=UDP SPT=68 DPT=67 LEN=308

However, when Firestarter is off, DHCPACK will happen immediately, and /var/log/syslog records lines like:

Feb 10 07:44:51 dhcp-server dnsmasq[27685]: DHCPREQUEST(eth0) 192.168.X.X 11:22:33:44:55:66
Feb 10 07:44:51 dhcp-server dnsmasq[27685]: DHCPACK(eth0) 192.168.X.X 11:22:33:44:55:66 dhcp-client

likewise DHCPOFFERS work when Firestarter is off:

(after 'sudo dhclient -r' on dhcp-client)
Feb 10 07:49:23 dhcp-server dnsmasq[27685]: DHCPRELEASE(eth0) 192.168.X.X 11:22:33:44:55:66

(after 'sudo dhclient' on dhcp-client)
Feb 10 07:49:26 dhcp-server dnsmasq[27685]: DHCPDISCOVER(eth0) 192.168.X.X 11:22:33:44:55:66
Feb 10 07:49:26 dhcp-server dnsmasq[27685]: DHCPOFFER(eth0) 192.168.X.X 11:22:33:44:55:66
Feb 10 07:49:26 dhcp-server dnsmasq[27685]: DHCPREQUEST(eth0) 192.168.X.X 11:22:33:44:55:66
Feb 10 07:49:26 dhcp-server dnsmasq[27685]: DHCPACK(eth0) 192.168.X.X 00:40:05:3d:b7:66 dhcp-client

If I try to set up Firestarter to allow DHCP traffic from 0.0.0.0 with either an "allow connections from" or "allow service" rule, I get the same behavior as if there is no such rule.

In Firestarter preferences|advanced options, the "block broadcast" boxes are empty. Also, in preferences|network settings, I have unchecked the "enable DHCP for the local network" box, since otherwise it complains it can't start when the dhcpd service is stopped (which it must to be allow dnsmasq to provide DHCP services).

I agree with ubun2-fan that having some option on Firestarter to let this work correctly would be nice. It seems like it should be possible, as it obviously works fine when using dhcpd to provide DHCP services.

FYI for anyone with the same issues, I had to enter the following statement in a terminal window:

sudo iptables -A INPUT --in-interface ethX --protocol udp -s 0.0.0.0 --source-port 68 -d 255.255.255.255 --destination-port 67 -j ACCEPT

replacing "ethX" with the interface that's appropriate for your setup (whichever one handles the local LAN).

I'm not sure if it will work in the /etc/firestarter/user-pre file, but this clearly indicates where the problem is.

[Simon Kelley (simon-thekelleys)]

A useful bit of information here: ISC dhcpd uses raw sockets to grab incoming packets before they pass through the IP stack and IP tables, it therefore doesn't suffer from problems caused by broken firewall rules. Dnsmasq uses standard IP sockets so that all incoming packets are filtered by iptables.

It is therefore not the case that having dhcpd work with firestarter means that the problem is solved and firestarter just has to do the same for dnsmasq as for dhcpd. WIth dhpcd the problem is moot, but with dnsmasq firestarter really has to get it right.

From the dnsmasq FAQ:

Q: I'm using dnsmasq on a machine with the Firestarter firewall, and
   DHCP doesn't work. What's the problem?

A: This a variant on the iptables problem. Explicit details on how to
   proceed can be found at
   http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2005q3/000431.html

Cheers,

SImon.

[xlynx (xlynx)]

jaunty with dnsmasq. bug still present. firestarter launches dnsmasq but blocks traffic to it. The workaround /etc/firestarter/user-pre doesn't seem to work.

[ded (ded-launchpad)]

dnsmasq takes care of so many headaches for a small network, this problem was really killing me since firestarter is probably the best gui front-end to iptables I've found.

But the above problem was plaguing me and the fix to user-pre above didn't seem to help.

In case anyone does what I did, I want to post the solution. I cut and pated the above-line from my browser into the user-pre file and it didn't work. What I finally discovered after banging my head on this one for several days was that the --sport and --dport argument got converted to and en-dash or some such non-ascii character by the browser and were invalid.

When you past the above, make sure to change them!

I found this by running "firestarter --start" from the command line, which will echo all the iptables errors to the console. I found several other problems with my firestarter configuration this way as well. For example, I found that it was unable to resolve the "hostnames" I used in several rules, so they weren't getting into the firewall. I had to hard-code IP addresses instead.

I hope this helps someone else.

Regards,

ded

[Xeletron (xeletron)]

It could also be that you have a adsl modem what does not resolve all
the names for you as you want, like say a Tomson modem, but if you are
correct in this, why does it do what it has to do, with the ' user-pre'
addition in my case and probably someone elses' .
regards.

On wo, 2009-07-08 at 15:48 +0000, ded wrote:

> dnsmasq takes care of so many headaches for a small network, this
> problem was really killing me since firestarter is probably the best gui
> front-end to iptables I've found.
>
> But the above problem was plaguing me and the fix to user-pre above
> didn't seem to help.
>
> In case anyone does what I did, I want to post the solution. I cut and
> pated the above-line from my browser into the user-pre file and it
> didn't work. What I finally discovered after banging my head on this
> one for several days was that the --sport and --dport argument got
> converted to and en-dash or some such non-ascii character by the browser
> and were invalid.
>
> When you past the above, make sure to change them!
>
> I found this by running "firestarter --start" from the command line,
> which will echo all the iptables errors to the console. I found several
> other problems with my firestarter configuration this way as well. For
> example, I found that it was unable to resolve the "hostnames" I used in
> several rules, so they weren't getting into the firewall. I had to
> hard-code IP addresses instead.
>
> I hope this helps someone else.
>
> Regards,
>
> ded
>

[Xeletron (xeletron)]

when i ran into this problem again, i opened a the dhcp port for anyone and that worked fine too as i use a non routable ip-range in mij network.

hope this helps if someone google's this.

[Phillip Susi (psusi)]

This package has been removed from Ubuntu. Closing all related bugs.