Prev: IPtables - forwarding question
Next: techradar says win7 has killed the linux desktop
From: Mike Jones on 18 Jun 2010 08:54
Responding to buck:

> Mike Jones <luck(a)dasteem.invalid> wrote in
> news:pan.2010.06.16.20.33.14(a)dasteem.invalid:
>
>> # === SERVER === #
>>
>> IPT="/usr/sbin/iptables"
>>
>> NIC_LAN="eth1"
>> PORTS_DHCP="53,67,68,4567"
>>
>> $IPT -F;
>> $IPT -X;
>> $IPT -P FORWARD DROP
>> $IPT -P INPUT DROP
>> $IPT -P OUTPUT DROP
>> $IPT -A INPUT -i lo -j ACCEPT
>> $IPT -A OUTPUT -o lo -j ACCEPT
>>
>> /bin/echo "1" > /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses
>> /bin/echo "0" > /proc/sys/net/ipv4/conf/all/accept_source_route
>> /bin/echo "0" > /proc/sys/net/ipv4/conf/all/accept_redirects
>>
>> $IPT -A INPUT -i $NIC_LAN -p udp \
>> -m multiport --ports $PORTS_DHCP \
>> -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT $IPT -A OUTPUT -o
>> $NIC_LAN -p udp \
>> -m multiport --ports $PORTS_DHCP \
>> -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
>
>> If I take this line in the server firewall...
>>
>> $IPT -A OUTPUT -o $NIC_LAN -p udp \
>> -m multiport --ports $PORTS_DHCP \
>> -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
>>
>> ...and change it to,
>>
>> $IPT -A OUTPUT -o $NIC_LAN -p udp \
>> -m multiport --ports $PORTS_DHCP \
>> -m state --state ESTABLISHED,RELATED -j ACCEPT
>>
>> (Just cut the "NEW" from the "OUTPUT")
>>
>> ...then the client can't connect.
>
>> Thoughts? Comments?
>
> Ask Simon, the author of dnsmasq.
>
> Assuming you took my previous advice to check the connection in
> /proc/net/ip_conntrack and that you see an ESTABLISHED connection on the
> server when the client cannot connect, my guess is that the connection
> is in fact terminated and a new one created.



From: /proc/net/ip_conntrack while not allowing NEW OUTPUT on the server
box (as in above example)...


udp 17 27 src=0.0.0.0 dst=255.255.255.255
sport=68 dport=67 packets=2 bytes=1152 [UNREPLIED]
src=255.255.255.255 dst=0.0.0.0 sport=67 dport=68
packets=0 bytes=0 mark=0 use=1

....which seems to indicate the port 67\68 thing is indeed, as far as
IPtables is concerned, a NEW connection, even though its something being
fed back in response to the client request.


Interestingly, I also spotted this...

udp 17 21 src=127.0.0.1 dst=127.0.0.1
sport=41975 dport=123 packets=4 bytes=960 [UNREPLIED]
src=127.0.0.1 dst=127.0.0.1 sport=123 dport=41975
packets=0 bytes=0 mark=0 use=1

....which means I'd have been blocking my ntpd LAN time-checks too.

So, nothing wrong with dnsmasq then. ;)

--
*=( http://www.thedailymash.co.uk/
*=( For all your UK news needs.
First  |  Prev  | 
Pages: 1 2
Prev: IPtables - forwarding question
Next: techradar says win7 has killed the linux desktop