DHCP not ACK for DHCPInform request

I posted a while ago about inconsistent subnet masks ("Inconsistent
subnet mask assigned for VPN connection in RRAS") for a specific route
when we connect via VPN. This issue is intermittent and, after more
investigation, appears to happen only on Vista clients.


To recap:
We have a win2k3 RRAS server serving up VPN connectivity. The network
address range is 10.0.96.0/255.255.252.0. When VPN clients connect,
they receive an address in the 10.0.96.0 range with subnet
255.255.255.255 and no gateway (when the "Use default gateway on
remote network" checkbox is unchecked). Quite often, clients are
unable to access server resources in the 10.0.98.0 range. When we do a
route print, we see something
like this:

10.0.96.0 255.255.255.0 10.0.96.4 10.0.96.4 1

When it works, we see:

10.0.96.0 255.255.252.0 10.0.96.4 10.0.96.4 1


Looking at the problem more closely, we see that the client broadcasts
a DHCPInform request. In a successful connection the DHCP server sends
back an ACK which contains relevant info, including the desired subnet
mask.

On an unsuccessful connection, we see that after the initial
DHCPInform broadcast followed by another DHCPInform after about 3 to
4 seconds. There is no DHCPACK from the DHCP server to the client IP.
When we look at the DHCP Relay stats, we see that it is indeed
forwarding these requests and that it is receiving replies - "Requests
received" increase by 2 and "Replies received" increase by 2.

Monitoring packets on the the DHCP server, we see that it is sending
back ACKS with the approriate info but it does not seem to get to the
client.

Firewall is turned off and disabled on the client end.

Any ideas?

Due to massive user pushback (including the company owners), we cannot
enable the "Use default gateway on remote network".

Updating my post (title is misleading, actually - DHCP server does
indeed ACK back). Anyways, after comparing packets between failed and
successful DHCPINFORMS it looks like the GOOD is Unicast while the
FAIL is broadcast. Could this be a factor? I think DHCP Relay RFC said
something about supporting both...

On Wed, 13 May 2009 10:56:24 -0700,
Peakbagger66_r3m0v3_th15_@hotmail.com wrote:

>I posted a while ago about inconsistent subnet masks ("Inconsistent
>subnet mask assigned for VPN connection in RRAS") for a specific route
>when we connect via VPN. This issue is intermittent and, after more
>investigation, appears to happen only on Vista clients.
>
>
>To recap:
>We have a win2k3 RRAS server serving up VPN connectivity. The network
>address range is 10.0.96.0/255.255.252.0. When VPN clients connect,
>they receive an address in the 10.0.96.0 range with subnet
>255.255.255.255 and no gateway (when the "Use default gateway on
>remote network" checkbox is unchecked). Quite often, clients are
>unable to access server resources in the 10.0.98.0 range. When we do a
>route print, we see something
>like this:
>
>10.0.96.0 255.255.255.0 10.0.96.4 10.0.96.4 1
>
>When it works, we see:
>
>10.0.96.0 255.255.252.0 10.0.96.4 10.0.96.4 1
>
>
>Looking at the problem more closely, we see that the client broadcasts
>a DHCPInform request. In a successful connection the DHCP server sends
>back an ACK which contains relevant info, including the desired subnet
>mask.
>
>On an unsuccessful connection, we see that after the initial
>DHCPInform broadcast followed by another DHCPInform after about 3 to
>4 seconds. There is no DHCPACK from the DHCP server to the client IP.
>When we look at the DHCP Relay stats, we see that it is indeed
>forwarding these requests and that it is receiving replies - "Requests
>received" increase by 2 and "Replies received" increase by 2.
>
>Monitoring packets on the the DHCP server, we see that it is sending
>back ACKS with the approriate info but it does not seem to get to the
>client.
>
>Firewall is turned off and disabled on the client end.
>
>Any ideas?
>
>Due to massive user pushback (including the company owners), we cannot
>enable the "Use default gateway on remote network".