From: Mike Jones on

Slackware 12.2 - as supplied dnsmasq\iptables.

If I included...

$IPT -A OUTPUT -o $NIC_LAN -p udp \
-m multiport --ports $PORTS_DHCP \
-m state --state NEW -j DROP

(PORTS_LAN = 53.67.68.1025:65545 dnsmasq.conf = "min-port=1025")

....in my routerbox firewall, my client machines can't get a DHCP connect.
However, even with...

$IPT -A INPUT -i $NIC_ONE -p tcp -m state --state NEW -j DROP
$IPT -A INPUT -i $NIC_ONE -p udp -m state --state NEW -j DROP
$IPT -A INPUT -i $NIC_ONE -p tcp --syn -j DROP
$IPT -A INPUT -i $NIC_ONE -f -j DROP

....in my client box's firewalls, they can get a DHCP connect.

I'm scratching my head at this one.

Is this a glitch, or am I missing something?

--
*=( http://www.thedailymash.co.uk/
*=( For all your UK news needs.
From: Grant on
On Wed, 9 Jun 2010 18:32:34 +0000 (UTC), Mike Jones <luck(a)dasteem.invalid> wrote:

>
>Slackware 12.2 - as supplied dnsmasq\iptables.
>
>If I included...
>
>$IPT -A OUTPUT -o $NIC_LAN -p udp \
>-m multiport --ports $PORTS_DHCP \
>-m state --state NEW -j DROP
>
>(PORTS_LAN = 53.67.68.1025:65545 dnsmasq.conf = "min-port=1025")
>
>...in my routerbox firewall, my client machines can't get a DHCP connect.
>However, even with...
>
>$IPT -A INPUT -i $NIC_ONE -p tcp -m state --state NEW -j DROP
>$IPT -A INPUT -i $NIC_ONE -p udp -m state --state NEW -j DROP
>$IPT -A INPUT -i $NIC_ONE -p tcp --syn -j DROP
>$IPT -A INPUT -i $NIC_ONE -f -j DROP
>
>...in my client box's firewalls, they can get a DHCP connect.
>
>I'm scratching my head at this one.
>
>Is this a glitch, or am I missing something?

Perhaps update dnsmasq? I update dnsmasq with slack-11, not running
12.2 here.

Latest source tarball:

http://www.thekelleys.org.uk/dnsmasq/dnsmasq-2.55.tar.gz

Simple to install: 'make && sudo make install' --> it goes to /usr/local
area by default and is thus seen by OS before the installed dnsmasq in
usual place (assuming default $PATH). No 'make uninstall', but is easy
to take out from /usr/local/* if required. The box through which this
message passed uses this latest release of dnsmasq.

Grant.
--
http://bugs.id.au/
From: buck on
Mike Jones <luck(a)dasteem.invalid> wrote in
news:pan.2010.06.09.18.33.36(a)dasteem.invalid:

>
> Slackware 12.2 - as supplied dnsmasq\iptables.
>
> If I included...
>
> $IPT -A OUTPUT -o $NIC_LAN -p udp \
> -m multiport --ports $PORTS_DHCP \
> -m state --state NEW -j DROP
>
> (PORTS_LAN = 53.67.68.1025:65545 dnsmasq.conf = "min-port=1025")

The highest possible port is 65535 not 65545. Shorthand would be 1025:
(omit the port number to the right of the colon).

> ...in my routerbox firewall, my client machines can't get a DHCP
> connect. However, even with...
>
> $IPT -A INPUT -i $NIC_ONE -p tcp -m state --state NEW -j DROP
> $IPT -A INPUT -i $NIC_ONE -p udp -m state --state NEW -j DROP
> $IPT -A INPUT -i $NIC_ONE -p tcp --syn -j DROP
> $IPT -A INPUT -i $NIC_ONE -f -j DROP
>
> ...in my client box's firewalls, they can get a DHCP connect.
>
> I'm scratching my head at this one.

What makes you think DHCP can be firewalled? I don't know about
dnsmasq, but I can assure you that ISC dhcpd cannot be firewalled.
The only way to prevent the assignment if an IP with ISC dhcpd is to
use deny unknown-clients; My _guess_ is that the dhcp deamon resorts
to raw sockets if udp ports 67 and 68 are blocked. Regardless, it
somehow manages to communicate with the client.
--
buck
From: Mike Jones on
Responding to buck:

> Mike Jones <luck(a)dasteem.invalid> wrote in
> news:pan.2010.06.09.18.33.36(a)dasteem.invalid:
>
>
>> Slackware 12.2 - as supplied dnsmasq\iptables.
>>
>> If I included...
>>
>> $IPT -A OUTPUT -o $NIC_LAN -p udp \
>> -m multiport --ports $PORTS_DHCP \
>> -m state --state NEW -j DROP
>>
>> (PORTS_LAN = 53.67.68.1025:65545 dnsmasq.conf = "min-port=1025")
>
> The highest possible port is 65535 not 65545. Shorthand would be 1025:
> (omit the port number to the right of the colon).


Typo, but thanks for the 1024: tip.


>> ...in my routerbox firewall, my client machines can't get a DHCP
>> connect. However, even with...
>>
>> $IPT -A INPUT -i $NIC_ONE -p tcp -m state --state NEW -j DROP $IPT -A
>> INPUT -i $NIC_ONE -p udp -m state --state NEW -j DROP $IPT -A INPUT
>> -i $NIC_ONE -p tcp --syn -j DROP $IPT -A INPUT -i $NIC_ONE -f -j DROP
>>
>> ...in my client box's firewalls, they can get a DHCP connect.
>>
>> I'm scratching my head at this one.
>
> What makes you think DHCP can be firewalled?


Coz I firewalled it. :)

Actually, I've got the LAN-facing NIC taking local DHCP calls from the
LAN, so that isolates things from the web. Like I said, I've also got the
client machines happily dropping incoming NEW traffic on the DHCP ports,
but if I block outgoing NEW on the router, no client access. Curiously
enough, I also have outgoing NEW dropped on my WWW-facing NIC, and that
doesn't seem to bother my ISP logon.


> I don't know about
> dnsmasq, but I can assure you that ISC dhcpd cannot be firewalled. The
> only way to prevent the assignment if an IP with ISC dhcpd is to use
> deny unknown-clients; My _guess_ is that the dhcp deamon resorts to raw
> sockets if udp ports 67 and 68 are blocked. Regardless, it somehow
> manages to communicate with the client.

I've nailed things down to "query-port=5151" now, and things still work
the same. The router needs to send out those NEW packets if the client is
to get their connection data.

I'm wondering if IPtables sees them as NEW because they're on different
outgoing ports, but the client sees them as incoming ESTABLISHED,RELATED.

Maybe its an IPtables thing?

--
*=( http://www.thedailymash.co.uk/
*=( For all your UK news needs.
From: buck on
Mike Jones <luck(a)dasteem.invalid> wrote in
news:pan.2010.06.10.16.54.29(a)dasteem.invalid:

> I'm wondering if IPtables sees them as NEW because they're on
> different outgoing ports, but the client sees them as incoming
> ESTABLISHED,RELATED.
>
> Maybe its an IPtables thing?

Does
[cat|less|most] /proc/net/ip_contrack
help you decide if that's the case? I'm pretty sure that iptables makes
its decisions about state based on the entries there.
--
buck