PFSense DHCP Server doesn't work with RHEL 6 machines



  • I have a DHCP Server working on PFSense 2.4.4. While it works perfectly with RHEL 7/CentOS 7 machines, it doesn't work on RHEL6/CentOS 6 (both with fixed IP or dynamic range).

    This is what DHCP Server Logs show (IP and MAC are obfuscated):

    DHCPREQUEST for xxx.xx.255.15 from aa:bb:cc:dd:ee:ff via bge0
    DHCPACK on xxx.xx.255.15 to aa:bb:cc:dd:ee:ff via bge0
    send_packet: Host is down
    dhcp.c:3976: Failed to send 318 byte long packet over fallback interface.
    

    Here is what service network restart shows in CentOS 6:

    alt text

    And here is what /var/log/messages shows (xxx.xxx.255.3 is the Pfsense DHCP Server address; xxx.xxx.255.1 is the default route; xxx.xxx.255.15 is the supposed address that should be bound to the machine):

    0_1547135880218_log.png

    Lastly, here is my PFSense server info if it helps:

    BIOS Vendor: Dell Inc.
    Version: 2.6.0
    Release Date: Tue Oct 31 2017

    Version 2.4.4-RELEASE (amd64)
    built on Thu Sep 20 09:03:12 EDT 2018
    FreeBSD 11.2-RELEASE-p3

    CPU Type Intel(R) Xeon(R) CPU E5-2620 v3 @ 2.40GHz
    24 CPUs: 2 package(s) x 6 core(s) x 2 hardware threads
    AES-NI CPU Crypto: Yes (inactive)

    I've tried rebooting those Centos 6 machines, rebooting PFSense, and I made sure the machines and PFSense packages are all updated. Nothing works.

    Any help is appreciated.



  • After struggling with this I found this in DHCP Server option in PfSense:

    Additional BOOTP/DHCP Options

    I configured it like this:

    alt text

    Turns out DHCP wasn't providing the Subnet Mask to CentOS 6 instances and with this option enabled, the mask is appended to the lease file.


  • LAYER 8 Global Moderator

    Sorry but NO...

    How would you think this error

    Failed to send 318 byte long packet over fallback interface.

    Has anything to do with the mask of the IP for the client?

    And your accepting that answer as correct on stacks - Sorry dude but NO...



  • Hi, John. No need to be harsh.

    I'm just explaining what solved the problem and got ride of those errors in the log, since other people might find themselves in the same situation. The errors aren't necessarily related, but are a consequence of this problem since the server and the machines are trying to communicate.

    What we debugged here indicates that DHCP communicated with the machine, but it wasn't able to set the IP. When the DHCP Ack was sent, it couldn't find the host because it didn't have an IP.


  • LAYER 8 Global Moderator

    No that did NOT solve your problem!!!

    You post an error, then says something completely unrelated and also pointless, since the mask is always included in the offer.. fixed it... Which is just plain not correct.

    Did you sniff to see what was in the offer after the discover?


  • Rebel Alliance Netgate Administrator

    I fired up a test VM of CentOS 6.10 minimal, got a DHCP address.

    Were you able to pull a Packet Capture on the switch to see the DHCP transaction?


  • LAYER 8 Global Moderator

    No he did not would be my guess, or he would of seen that the mask is already included in the offer..



  • Yes, we checked the DHCP transaction. Let me be clearer: the mask wasn't appended to the lease file, even if the offer had the mask. With that option enabled, the mask is now appended to the lease file that dhclient script uses to set the IP.


  • Rebel Alliance Netgate Administrator

    Do you still have a copy of the pcap file that we can see?

    Edit:
    DHCP request should be in RFC1918 space, no need to obscure that data.


Log in to reply