Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    Re: pfSense RC3 - DHCP Fail-over Issues [SOLVED]

    2.0-RC Snapshot Feedback and Problems - RETIRED
    1
    2
    2.5k
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • R
      Rhongomiant
      last edited by

      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.

      1 Reply Last reply Reply Quote 0
      • R
        Rhongomiant
        last edited by

        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.

        1 Reply Last reply Reply Quote 0
        • First post
          Last post
        Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.