[Dnsmasq-discuss] Windows Server 2008 R2 issue

[Brian Haley]

On 10/15/2012 06:58 AM, Simon Kelley wrote:
> On 13/10/12 17:34, Brian Haley wrote:
>> Hi,
>>
>> I'm having trouble getting a Windows Server 2008 R2 virtual machine to
>> get a
>> lease from dnsmasq running on Ubuntu Linux.  An R1, and any other OS,
>> has no
>> problems.  The version of dnsmasq is 2.58-3.
>>
>> My config is as follows:
>>
>> eth0 - public interface - IP 15.3.2.1 (that's not my real IP)
>> brx1 - private bridge   - IP 10.13.128.1
>> vnetX - taps attached to the bridge
>>
>> Here's the ps output for dnsmasq:
>>
>> 20761 ?        S      0:00 dnsmasq --strict-order --bind-interfaces
>> --conf-file=/var/lib/nova/networks/dnsmasq.conf --domain=novalocal
>> --pid-file=/var/lib/nova/networks/nova-brx1.pid
>> --listen-address=10.13.128.1
>> --except-interface=lo --dhcp-range=10.13.128.2,static,255.255.224.0,900s
>> --dhcp-lease-max=8192
>> --dhcp-hostsfile=/var/lib/nova/networks/nova-brx1.conf
>> --dhcp-script=/usr/bin/nova-dhcpbridge --leasefile-ro

<snip>

>> But for the R2 server I see:
>>
>> 21:26:10.522156 02:16:3e:4b:cc:53 > ff:ff:ff:ff:ff:ff, ethertype IPv4
>> (0x0800),
>> length 342: (tos 0x0, ttl 128, id 346, offset 0, flags [none], proto
>> UDP (17),
>> length 328)
>>      0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from
>> 02:16:3e:4b:cc:53,
>> length 300, xid 0xcc8a146d, secs 6656, Flags [Broadcast]
>>            Client-Ethernet-Address 02:16:3e:4b:cc:53
>>            Vendor-rfc1048 Extensions
>>              Magic Cookie 0x63825363
>>              DHCP-Message Option 53, length 1: Discover
>>              NOAUTO Option 116, length 1: Y
>>              Client-ID Option 61, length 7: ether 02:16:3e:4b:cc:53
>>              Hostname Option 12, length 15: "WIN-OE4E9RLAG6M"
>>              Vendor-Class Option 60, length 8: "MSFT 5.0"
>>              Parameter-Request Option 55, length 12:
>>                Subnet-Mask, Domain-Name, Default-Gateway,
>> Domain-Name-Server
>>                Netbios-Name-Server, Netbios-Node, Netbios-Scope,
>> Router-Discovery
>>                Static-Route, Classless-Static-Route,
>> Classless-Static-Route-Microsoft, Vendor-Option
>>
>> 21:26:10.522590 02:16:3f:0c:10:0d > ff:ff:ff:ff:ff:ff, ethertype IPv4
>> (0x0800),
>> length 345: (tos 0x0, ttl 64, id 58362, offset 0, flags [none], proto
>> UDP (17),
>> length 331)
>>      15.3.2.1.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 303, xid
>> 0xcc8a146d, secs 6656, Flags [Broadcast]
>>            Your-IP 10.13.128.194
>>            Server-IP 10.13.128.1
>>            Client-Ethernet-Address 02:16:3e:4b:cc:53
>>            Vendor-rfc1048 Extensions
>>              Magic Cookie 0x63825363
>>              DHCP-Message Option 53, length 1: Offer
>>              Server-ID Option 54, length 4: 10.13.128.1
>>              Lease-Time Option 51, length 4: 900
>>              RN Option 58, length 4: 450
>>              RB Option 59, length 4: 787
>>              Subnet-Mask Option 1, length 4: 255.255.224.0
>>              BR Option 28, length 4: 10.13.159.255
>>              Default-Gateway Option 3, length 4: 10.13.128.1
>>              Domain-Name-Server Option 6, length 4: 10.13.128.1
>>              Domain-Name Option 15, length 9: "novalocal"
>>
>> Notice the source IP address here is that of my Internet-facing
>> interface, not
>> the IP on the bridge.  That's actually causing me to drop the packet
>> on the
>> bridge due to an ebtables rule that only allows responses from
>> 10.13.128.1 (for
>> security reasons).  Since I'm starting dnsmasq to only listen on that
>> IP, I
>> don't know why it's responding using the other, unless the Linux
>> network stack
>> is doing that?
>>
>> The only thing I've noticed that's different is that in the R2 request
>> there is
>> an additional option:
>>
>>     NOAUTO Option 116, length 1: Y
>>
>> Is that possibly causing dnsmasq to respond differently?  I haven't
>> dug into the
>> code yet, figured I'd ask on the list in case it's been seen before.
>
>
> The option 116 thing is a red herring. I think the crucial difference
> between R1 and R2 is that R2 is R2 is setting the Broadcast flag in its
> requests, so that dnsmasq is sending replies to 255.255.255.255.

Thanks, I looked at that trace many times and never noticed that, 
strange that R2 would have changed something like this.

> Dnsmasq is not explicitly setting the source address, so that's coming
> from the Linux kernel, it looks like it's making a bad call under these
> circumstances.

Is dnsmasq choosing the interface?  Like using SO_BINDTODEVICE?  I 
should go look, but it must be doing something since it's going out onto 
the bridge and not out eth0 where my default route is pointing.  I would 
have hoped the kernel would have chosen the address on the bridge, but I 
can look into why it didn't.

> A tweak to your firewall rules to accept all packets to 255.255.255.255
> may be a good solution.

The problem isn't the destination address, but the source, since we're 
trying to catch anyone spoofing the DHCP server, but I may be able to 
write an iptables rule to catch this case and change the source IP to be 
correct.

Thanks,

-Brian