# DNSMASQ/DHCP and IPTABLES probs + DNS question [SOLVED]

## HydroSan

I'm having a problem with my client computers not getting proper DHCP leases from my Linux router. I've traced the problem back to my IPTABLES configuration, as DHCP works fine with it disabled. I got a script a while back from #gentoo (thanks to whoever pointed me to it): 

```
#!/bin/sh

INTERNET=ppp0

SUBNET_1=eth1

iptables -t filter --flush

iptables -t nat --flush 

iptables -F INPUT

iptables -F FORWARD

iptables -F OUTPUT

iptables -P INPUT DROP

iptables -P FORWARD ACCEPT

iptables -P OUTPUT DROP

#=====================#

# LOCALHOST interface #

#---------------------#

iptables -A INPUT  -i lo -j ACCEPT

iptables -A OUTPUT -o lo -j ACCEPT

#================#

# All interfaces #

#================#

# Specify which ICMP-packets to allow

iptables -A INPUT  -p icmp --icmp-type echo-reply -j ACCEPT

iptables -A INPUT  -p icmp --icmp-type destination-unreachable -j ACCEPT

iptables -A INPUT  -p icmp --icmp-type source-quench -j ACCEPT

iptables -A INPUT  -p icmp --icmp-type time-exceeded -j ACCEPT

iptables -A INPUT  -p icmp --icmp-type parameter-problem -j ACCEPT

iptables -A INPUT  -p icmp -j DROP

#=====================#

# INTERNET interface  #

#---------------------#

# Refuse forwarding from the internet

iptables -A FORWARD -i $INTERNET -s 192.168.0.0/24 -j DROP

# Block all calls pretending being from the internal network

iptables -A INPUT  -i $INTERNET -s 192.168.0.0/24 -j DROP

# Accept all already set up connections

iptables -A INPUT  -i $INTERNET -p tcp ! --syn -j ACCEPT

# Allow everything to go out of the networking card to the internet

iptables -A OUTPUT -o $INTERNET -j ACCEPT

# Services to allow:

# DNS

iptables -A INPUT  -i $INTERNET -p udp --sport 53 -j ACCEPT

iptables -A INPUT  -i $INTERNET -p tcp --sport 53 -j ACCEPT

# WWW

iptables -A INPUT  -i $INTERNET -p tcp --dport 80 -j ACCEPT

# BT

iptables -A INPUT  -i $INTERNET -p tcp --dport 6881:6999 -j ACCEPT

# Deny identd instead of dropping it, for speed increase

iptables -A INPUT  -i $INTERNET -p tcp --dport 113 -j REJECT

#=====================#

# SUBNET_1 interface  #

#---------------------#

# Refuse everybody who have an illegal IP-address

iptables -A INPUT  -i $SUBNET_1 ! -s 192.168.0.0/24 -j DROP

# Accept all already set up connections

iptables -A INPUT  -i $SUBNET_1 -p tcp ! --syn -j ACCEPT

# Allow everything to go out of the computer

iptables -A OUTPUT -o $SUBNET_1 -j ACCEPT

# Don't allow forwarding from incorrect IPs.

iptables -A FORWARD -i $SUBNET_1 ! -s 192.168.0.0/24 -j DROP

# Services to allow:

# DNS

iptables -A INPUT  -i $SUBNET_1 -s 192.168.0.0/24 -p udp --dport 53 -j ACCEPT

iptables -A INPUT  -i $SUBNET_1 -s 192.168.0.0/24 -p tcp --dport 53 -j ACCEPT

# DHCP

iptables -A INPUT  -i $SUBNET_1 -s 192.168.0.0/24 -p udp --dport 67:68 -j ACCEPT

# SSH

iptables -A INPUT  -i $SUBNET_1 -s 192.168.0.0/24 -p tcp --dport 9573 -j ACCEPT

# WWW

iptables -A INPUT  -i $SUBNET_1 -s 192.168.0.0/24 -p tcp --dport 80 -j ACCEPT

# SMTP

iptables -A INPUT  -i $SUBNET_1 -s 192.168.0.0/24 -p tcp --dport 25 -j ACCEPT

iptables -A INPUT  -i $SUBNET_1 -s 192.168.0.0/24 -p tcp --dport 465 -j ACCEPT

# IMAP

iptables -A INPUT  -i $SUBNET_1 -s 192.168.0.0/24 -p tcp --dport 993 -j ACCEPT

iptables -A INPUT  -i $SUBNET_1 -s 192.168.0.0/24 -p tcp --dport 143 -j ACCEPT

# Samba

iptables -A INPUT  -i $SUBNET_1 -s 192.168.0.0/24 -p udp --dport 137 -j ACCEPT

iptables -A INPUT  -i $SUBNET_1 -s 192.168.0.0/24 -p udp --dport 138 -j ACCEPT

iptables -A INPUT  -i $SUBNET_1 -s 192.168.0.0/24 -p tcp --dport 139 -j ACCEPT

#Webmin

iptables -A INPUT  -i $SUBNET_1 -s 192.168.0.0/24 -p tcp --dport 10000 -j ACCEPT

#===========#

# NAT setup #

#-----------#

iptables -t nat -A POSTROUTING -o $INTERNET -j MASQUERADE

echo 1 > /proc/sys/net/ipv4/ip_forward
```

Everything else works fine. Any help is appreciated. 

PART TWO

I was wondering also how or what the DNS function works or what it does, and how it could benefit me. 

Thanks for your help.

----------

## dsd

a few thoughts:

the following rules might be blocking it. i'm not sure how the technicalities of DHCP work, but at the time when a client requests a lease, they will not have a 192.168.0.x ip..

```
# Refuse everybody who have an illegal IP-address

iptables -A INPUT  -i $SUBNET_1 ! -s 192.168.0.0/24 -j DROP

# Don't allow forwarding from incorrect IPs.

iptables -A FORWARD -i $SUBNET_1 ! -s 192.168.0.0/24 -j DROP 
```

also... you are allowing UDP ports 67/68 for DHCP, maybe try enabling them for TCP as well - i can't get a clear answer from google whether DHCP uses udp or tcp.

as for the DNS part of dnsmasq, well, it acts as a small caching server by default. from a client pc on my network, if i resolve an address that hasn't been resolved in a while, e.g.

```
# dig yahoo.de

; <<>> DiG 9.2.3 <<>> yahoo.de

[snip]

;; ANSWER SECTION:

yahoo.de.               1800    IN      A       217.12.3.11

;; Query time: 38 msec
```

notice the 38 ms delay there. if i then resolve it again, right after, i get:

```
# dig yahoo.de

; <<>> DiG 9.2.3 <<>> yahoo.de

[snip]

;; ANSWER SECTION:

yahoo.de.               1790    IN      A       217.12.3.11

;; Query time: 1 msec
```

notice the speed increase, as dnsmasq has cached that result.

this will happen by default for clients that get a lease over DHCP (as long as DHCP tells them to use dns server 192.168.0.1). but on the machine running dnsmasq, if you want to take advantage of the DNS caching, you need to tell it to use the local nameserver in /etc/resolv.conf. but you also need to tell it the IP's of your ISP's nameservers so that it knows where to look for uncached results. on my dnsmasq server, my /etc/resolv.conf reads:

```
nameserver 192.168.0.1

nameserver 194.168.8.100

nameserver 212.23.8.1

nameserver 158.43.240.3
```

----------

## neysx

 *www.isc.org wrote:*   

> FIREWALL RULES
> 
> If you are running the DHCP server or client on a computer that's also acting as a firewall, you must be sure to allow DHCP packets through the firewall. In particular, your firewall rules _must_ allow packets from IP address 0.0.0.0 to IP address 255.255.255.255 from UDP port 68 to UDP port 67 through. They must also allow packets from your local firewall's IP address and UDP port 67 through to any address your DHCP server might serve on UDP port 68. Finally, packets from relay agents on port 67 to the DHCP server on port 67, and vice versa, must be permitted.
> 
> We have noticed that on some systems where we are using a packet filter, if you set up a firewall that blocks UDP port 67 and 68 entirely, packets sent through the packet filter will not be blocked. However, unicast packets will be blocked. This can result in strange behaviour, particularly on DHCP clients, where the initial packet exchange is broadcast, but renewals are unicast - the client will appear to be unable to renew until it starts broadcasting its renewals, and then suddenly it'll work. The fix is to fix the firewall rules as described above.
> ...

 

----------

## HydroSan

 *neysx wrote:*   

>  *www.isc.org wrote:*   FIREWALL RULES
> 
> If you are running the DHCP server or client on a computer that's also acting as a firewall, you must be sure to allow DHCP packets through the firewall. In particular, your firewall rules _must_ allow packets from IP address 0.0.0.0 to IP address 255.255.255.255 from UDP port 68 to UDP port 67 through. They must also allow packets from your local firewall's IP address and UDP port 67 through to any address your DHCP server might serve on UDP port 68. Finally, packets from relay agents on port 67 to the DHCP server on port 67, and vice versa, must be permitted.
> 
> We have noticed that on some systems where we are using a packet filter, if you set up a firewall that blocks UDP port 67 and 68 entirely, packets sent through the packet filter will not be blocked. However, unicast packets will be blocked. This can result in strange behaviour, particularly on DHCP clients, where the initial packet exchange is broadcast, but renewals are unicast - the client will appear to be unable to renew until it starts broadcasting its renewals, and then suddenly it'll work. The fix is to fix the firewall rules as described above.
> ...

 

I've got the gist of that, but am not too sure on how to implement it.   :Shocked:  Would my DHCP section look like:

```
iptables -A INPUT  -i $SUBNET_1 -s 0.0.0.0:255.255.255.255/24 -p udp --dport 67:68 -j ACCEPT 
```

This?

----------

## HydroSan

Apparently the line I just posted doesn't work. Can anyone give me an example of their own script? Thanks.

----------

## neysx

Sorry, I don't know anything about iptables but IMHO you need something with -A FORWARD to let packets through your firewall between your clients and your DHCP server.

----------

## DaveArb

 *HydroSan wrote:*   

> 
> 
> I've got the gist of that, but am not too sure on how to implement it.   Would my DHCP section look like:
> 
> ```
> ...

 

Close. Drop the -s parameter, all IPs is the default.

```
iptables -A INPUT  -i $SUBNET_1 -p udp --dport 67:68 -j ACCEPT 
```

Should turn the trick. If you ever need to indicate all IPs in CIDR notation, it would be 0.0.0.0/0 (I think, it's kind of a degenerate use).

Do you have an output rule for 67:68 on SUBNET_1 and I'm just not seeing it?

Dave

----------

## HydroSan

 *DaveArb wrote:*   

>  *HydroSan wrote:*   
> 
> I've got the gist of that, but am not too sure on how to implement it.   Would my DHCP section look like:
> 
> ```
> ...

 

...   :Crying or Very sad: 

It works now.

Thank you so much.

----------

## DaveArb

Cool deal! No reason to look sad, I made a mistake the other day much more obvious than that, I've been full-time in computers for longer than many on this forum have been alive.  :Wink: 

Dave

----------

