Navigation

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

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

    2.0-RC Snapshot Feedback and Problems - RETIRED
    1
    2
    2091
    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

        Products

        • Platform Overview
        • TNSR
        • pfSense Plus
        • Appliances

        Services

        • Training
        • Professional Services

        Support

        • Subscription Plans
        • Contact Support
        • Product Lifecycle
        • Documentation

        News

        • Media Coverage
        • Press
        • Events

        Resources

        • Blog
        • FAQ
        • Find a Partner
        • Resource Library
        • Security Information

        Company

        • About Us
        • Careers
        • Partners
        • Contact Us
        • Legal
        Our Mission

        We provide leading-edge network security at a fair price - regardless of organizational size or network sophistication. We believe that an open-source security model offers disruptive pricing along with the agility required to quickly address emerging threats.

        Subscribe to our Newsletter

        Product information, software announcements, and special offers. See our newsletter archive to sign up for future newsletters and to read past announcements.

        © 2021 Rubicon Communications, LLC | Privacy Policy