Simon,
Okay. It doesn't appear to be the IP tables, but I did some digging.
If I run tcpdump on the host I get:
[0]akutz@legacy:~$ sudo tcpdump -ni en1 'udp port 67 and udp port 68'
tcpdump: verbose output suppressed, use -v or -vv for full protocol
decode
listening on en1, link-type EN10MB (Ethernet), capture size 65535 bytes
14:57:16.591186 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP,
Request from 00:18:8b:3e:29:3c, length 272
14:57:32.873143 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP,
Request from 00:23:df:58:53:3a, length 300
14:57:32.879882 IP 172.25.0.2.67 > 255.255.255.255.68: BOOTP/DHCP,
Reply, length 303
14:58:20.489057 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP,
Request from 00:18:8b:3e:29:3c, length 272
^C
4 packets captured
1086 packets received by filter
0 packets dropped by kernel
So it appears as if the VM's NIC, (coming from 0.0.0.0.68) is sending
a DHCP request to the broadcast address of the host's subnet and
getting a response from the DHCP server on the host's subnet, not the
DHCP server included with dnsmasq. I can verify this by looking at the
logs in the VM (OpenSUSE 11) in /var/log/messages. This line appears
over and over again:
linux dhclient; DHCPDISCOVER on eth0 to 255.255.255.255 port 67
interval x
I would think that this is a fairly normal set up, so what am I doing
incorrectly that the dnsmasq server isn't catching the DHCP request?
For completeness, here is the output from dnsmasq:
[130]akutz@legacy:src$ sudo ./dnsmasq -a 192.168.3.1 -b -f -F
192.168.3.15,192.168.3.254,255.255.255.0,192.168.3.255,1h -K -l /opt/
akin/dnsmasq.leases -d
dnsmasq: started, version 2.49 cachesize 150
dnsmasq: compile time options: IPv6 no-GNU-getopt no-DBus no-I18N DHCP
TFTP
dnsmasq: setting --bind-interfaces option because of OS limitations
dnsmasq-dhcp: DHCP, IP range 192.168.3.15 -- 192.168.3.254, lease time
1h
dnsmasq: reading /etc/resolv.conf
dnsmasq: using nameserver 172.16.100.250#53
dnsmasq: using nameserver 172.25.0.2#53
dnsmasq: read /etc/hosts - 5 addresses
dnsmasq-dhcp: DHCPDISCOVER(vboxnet0) 08:00:27:3f:36:92
dnsmasq-dhcp: DHCPOFFER(vboxnet0) 192.168.3.165 08:00:27:3f:36:92
dnsmasq-dhcp: DHCPDISCOVER(vboxnet0) 08:00:27:3f:36:92
dnsmasq-dhcp: DHCPOFFER(vboxnet0) 192.168.3.165 08:00:27:3f:36:92
dnsmasq-dhcp: DHCPDISCOVER(vboxnet0) 08:00:27:3f:36:92
dnsmasq-dhcp: DHCPOFFER(vboxnet0) 192.168.3.165 08:00:27:3f:36:92
dnsmasq-dhcp: DHCPDISCOVER(vboxnet0) 08:00:27:3f:36:92
dnsmasq-dhcp: DHCPOFFER(vboxnet0) 192.168.3.165 08:00:27:3f:36:92
dnsmasq-dhcp: DHCPDISCOVER(vboxnet0) 08:00:27:3f:36:92
dnsmasq-dhcp: DHCPOFFER(vboxnet0) 192.168.3.165 08:00:27:3f:36:92
dnsmasq-dhcp: DHCPDISCOVER(vboxnet0) 08:00:27:3f:36:92
dnsmasq-dhcp: DHCPOFFER(vboxnet0) 192.168.3.165 08:00:27:3f:36:92
dnsmasq-dhcp: DHCPDISCOVER(vboxnet0) 08:00:27:3f:36:92
dnsmasq-dhcp: DHCPOFFER(vboxnet0) 192.168.3.165 08:00:27:3f:36:92
dnsmasq-dhcp: DHCPDISCOVER(vboxnet0) 08:00:27:3f:36:92
dnsmasq-dhcp: DHCPOFFER(vboxnet0) 192.168.3.165 08:00:27:3f:36:92
Thanks!
--
-a
"Only two things are infinite, the universe and human stupidity, and
I'm not sure about the former." -- Einstein
On Aug 27, 2009, at 10:53 AM, Simon Kelley wrote:
Schley Andrew Kutz wrote:
I am attempting to use dnsmasq to more fully supply functionality
for my own project, akin (http://akutz.wordpress.com/2009/08/20/building-a-better-os-x-firewall-or-how-i-solved-the-nat-problem-for-virtualbox
). The DNS portion is working great, but DHCP requests are stuck
in an endless loop of DISCOVER,OFFER.
The options I use are:
sudo ./dnsmasq -a 192.168.3.1 -b -f -F
192.168.3.15,192.168.3.254,255.255.255.0,192.168.3.255,1h -K -l /
opt/ akin/dnsmasq.leases -d
I thought it might be an IP tables issue, but I set my deny rule
to log and no packets are getting dropped. Besides, I have a
static allowance for all traffic on the virtual interface that dns
masq is operating on.
Thoughts?
Look at the logs on the clients to see if they are getting the
OFFERs. If not look again at iptables.
Simon.
