Netgate m1n1wall

Author Topic: Re: pfSense RC3 - DHCP Fail-over Issues [SOLVED]  (Read 1215 times)

0 Members and 1 Guest are viewing this topic.

Offline Rhongomiant

  • Jr. Member
  • **
  • Posts: 30
  • Karma: +0/-0
    • View Profile
Re: pfSense RC3 - DHCP Fail-over Issues [SOLVED]
« on: July 25, 2011, 02:36:10 am »
I am using the AMD64 builds of pfSense 2.0 RC3. I have the same build running on an dedicated hardware and in a VM with CARP and DHCP fail-over configured on both. The dedicated hardware was installed with a build of AMD64 RC2. When I setup CARP and DHCP fail-over, I updated the dedicated hardware to the following build and installed the VM using pfSense-2.0-RC3-amd64-20110708-1843.iso. I have updated three times since the install. The current build on both is 2.0-RC3 Built On: Sun Jul 24 04:39:44 EDT 2011 and I have had the same issue on at least the last 2 of the builds I have used with the CARP and DHCP fail-over setup.

What I found is that on interfaces where I have strict rules, not just an allow any, DHCP was not being served to devices. Ultimately I had to add a rule allowing traffic to ports 519 and 520 on the IPs on each like interface on both pfSense devices.

In the log I would get messages like the one below. If needed I can get an entry from the secondary pfSense device.

Primary: dhcpd: DHCPREQUEST for 10.61.32.20 from 00:0b:db:7e:8e:5d via em1: not responding (recovering)

The question is should I have to create these rules or is pfSense supposed to create them automatically?

I ask because non of the documentation indicates that rules need to be created to allow DHCP fail-over to work as expected.
« Last Edit: July 31, 2011, 01:28:19 pm by Rhongomiant »

Offline Rhongomiant

  • Jr. Member
  • **
  • Posts: 30
  • Karma: +0/-0
    • View Profile
Re: pfSense RC3 - DHCP Fail-over Issues [SOLVED]
« Reply #1 on: July 31, 2011, 01:27:21 pm »
I filed Bug #1730 which was rejected and listed as not an issue. This issue does appear to be fixed.

Using build 2.0-RC3 (amd64) built on Fri Jul 29 22:14:50 EDT 2011 I have verified this issue is fixed by disabling my rules to allow traffic to ports 519 and 520 on each interface that has these rules. I also rebooted both firewalls and tested DHCP on multiple VLANs.