DHCP Server and WinXP clients

  • The pfsense DHCP server does disable/enable its ethernet connections after it is loaded and started. This causes WinXP clients that have automatically failed over to the alternate/random IP address range to remain there and therefore communications with pfsense is disrupted.

    Problem is most apparent after a reboot of pfsense without rebooting the XP clients.

  • Are your WinXP clients plugged directly into the pfSense box?? I have multiple machines running WinXP and the pfSense box plugged into a port network switch. Never had the problem you describe. I've rebooted the pfSense box multiple times.

  • A windows XP client configured for DHCP will attempt getting an IP again sooner or later. The issue you are describing should only happen if the pfSense is down while the client tries to renew it's lease and should solve itself after a short time. Never have seen this issue yet. Maybe bump up your leasetimes to a higher value to make it more unlikely to hit a downtime of your pfSense.

  • Hi rsw686, The WinXp client is plugged into a 8 port switch. This also happened when the Client was plugged in directly to the LAN port of pfsense. This problem may be specific to the interface cards. They are  ENL832-TX-RENT PCI ethernet adapters using the RL driver.

    You are right! The power for the switch comes from the pfsense box(just like a router). When the pfsense is powered down the xpClient senses the lost connection. The Xpclient performs its release/renew cycle prior to the DHCP server activation thereby getting a random IP. If the switch power is not cycled(soft reboot) the winXP client keep its last IP(Huba's Point). Note that most of the testing was done with the direct LAn connection that causes a problem both with a hard and soft boot.

    Hi Huba,When the pfsense box reboots the winXP client(Dell Inspiron 8500) senses the reboot and starts a release cycle for the IP address. Once the FreeBSD boot completes and the pfsense build starts the WinXP client starts a renew cycle. This cycle completes prior to the pfsense setting up its dhcpserver.
    An "ifdown LAN" and "Ifup LAN"  cycle started after the DHCPserver starts up would solve the problem. Perhaps this is already being done and somehow the IFcard is missing it?

    "Wake on lan" is not set for these interfaces. Should it be???

  • The switch part of these kind of nics don't see an interface going down. You can think of it being a nic that is connected to a switch on the same board. So if one interface goes down the other switchports are not affected by this. So this is no solution for you. Just let the clients sit for some time and they'll fetch an IP later.

    Btw, are you rebooting pfSense that often that this is really a big issue?

  • Thanks Hoba,
    The number of reboots has tapered down considerably. The biggest reason for reboots is that it is easier to edit the Config.xml file for a large number of NAT and Firewall entries than to enter them through the Web interface. The Port forwarding entries for the WAN interface contain 13 entries. With 2 WANs the number of entries increases to 26 and with 3 WANs to 39. Then there is corresponding Firewall entries. It was nice that the Firewall set was created automatically.

    You are right in that  my suggestion will not solve the problem for my setup. This is not really a big issue and should be just put on a to do list for the sake of completeness.

    When pfsense was first set up, with your help BTW, it was very disconcerting to find the laptop not connected to the box. Now its quite workable.

    Thanks again

  • You could always change XP setupso that it does not invent silly addresses when no dhcp server available, but sulks with no IP address.  In this situation it will retry more often.  Easier still is to have a separately powered switch so the clients do not think the network has gone / come back at all.

  • Hi Pootle, good to see that you are still active. OFF topic, BTW the other people that are running VMware are telling me that the performance is not bad.

Log in to reply