Re: DHCRELAY through IPTABLES Firewall

[Antony Stone <Antony@Soft-Solutions.co.uk>]

On Tuesday 29 October 2002 7:37 am, bigman@monster-solutions.net wrote:

> here is how I ended up fixing my problem. However I have just discovered it
> only works with one client. When I try to get another client to obtain an
> IP it does not work. Any ideas? Is DNAT limiting me on one MAC to pass
> through or something? I am lost here.

Please can you confirm whether this works at all for a client which does not 
have an IP address to start with (ie it's not a renewal, or a request for the 
last IP address it had).   I don't see how it can work for a totally clean 
client.

> 1)    turned off DHCPD and DHCRELAY on firewall
> 2)    iptables -t nat -A PREROUTING -i eth2 -p udp --dport 67 -j
> DNAT --to-destination 192.168.1.70
> 3)    iptables -A FORWARD -p udp -m multiport --dport 67,68 -j ACCEPT

Okay, what this is doing is taking the original client's DHCP request, which 
has the following characteristics:
Source IP address = 0.0.0.0
Destination IP address = 0.0.0.0
Source MAC address = client's mac address
Destinaton MAC address = FF:FF:FF:FF:FF:FF

The broadcast MAC address means it gets to your firewall.

The PREROUTING rule then sets a destination IP address, and the normal 
routing system of Linux gives it a source MAC address = your Firewall, and a 
destination MAC address = the DHCP server.

The request gets to the server, it allocates an IP address based on the MAC 
address of your firewall (because that's where the local packet came from; 
remember MAC addresses only work within physical subnets), and sends the 
response back again.

The response has:
Source IP address = 192.168.1.70
Destination IP address = assigned DHCP address
Source MAC address = DHCP server
Destination MAC address = Firewall

Therefore the firewall receives the packet (because of the destination MAC 
address), forwards the packet on to the destination IP address (because of 
your rule 3), and the client gets an IP address.

The bit which I don't think can work unless the client already had an IP 
address (and the request was just a renewal, or a check that it could have 
the last IP address it had used again), is when the firewall sends the 
response back to the client, because unless the client responds to an ARP 
request from the firewall, how does the firewall know which MAC address to 
send the answer back to ?

I can say that this is definitely not the asnwer to your problem, because 
DHCP requests & responses with definitely break across a router (such as a 
netfilter firewall) simply because of what happens to the MAC addresses.

If you want to allocate addresses on one subnet from a DHCP server on another 
subnet you must use DHCRELAY.

Antony.

-- 

It is also possible that putting the birds in a laboratory setting
inadvertently renders them relatively incompetent.

 - Daniel C Dennett