Navigation

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

    DHCP Client Issue

    DHCP and DNS
    6
    14
    1949
    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.
    • X
      xero9 last edited by

      Hi all,

      So I have a VERY frustrating issue that makes me want to leave pfSense as it’s such basic core functionality that is messing up.

      The firewall gets its IP using DHCP from my cable provider, which is all fine and dandy except I was having power outages and what was happening was everything was coming back up but the firewall would come back up before the modem and would not obtain an IP. Logically if the firewall doesn’t have an IP one would think it would try to renew periodically but it will go hours and take no action on its own and I have to log in and renew the lease.

      I’ve heard it’s because the Hiltron modems give a 192.168.100.0 IP before fully booting up and I even changed a setting a few months ago to delay 120 seconds or so before trying to obtain an IP but that still doesn’t work.

      My solution was to get a UPS, which of course is not a fix but a bandaid solution and of course the next power failure lasted longer than the UPS!

      1 Reply Last reply Reply Quote 0
      • Gertjan
        Gertjan last edited by

        Hi,

        On the Interfaces / WAN page, check "Advanced configuration".

        Then read https://docs.netgate.com/pfsense/en/latest/book/interfaces/ipv4-wan-types.html -you'll be recognizing your issue right away, and close to a solution ;)

        dd1b98fe-1ca6-406f-9081-6acbce8ae3de-image.png

        No "help me" PM's please. Use the forum.

        X 1 Reply Last reply Reply Quote 1
        • X
          xero9 @Gertjan last edited by

          @Gertjan
          Hi there,

          Thank you for the prompt reply :)

          So I did as you said and I see there are several protocol timing settings I can set, which is fine and maybe solve my problem, however when reading the document linked it has values such as 60 seconds and 5 minutes by default. To me, it seems it’s just simply not doing these.

          
          retry time;
          	     The retry statement determines the	time that must pass after the
          	     client has	determined that	there is no DHCP server	present	before
          	     it	tries again to contact a DHCP server.  By default, this	is
          	     five minutes.
          
          

          I would think after 5 minutes (after everything is back online 100%) pfSense would get its IP and be back in business. If it missed that mark, then 10 minutes, 15, 20, etc. after 8 hours it still doesn’t work and I simply reboot the firewall and it works makes me think something isn’t functioning the way it should.

          Am I missing something? I do appreciate your help!

          1 Reply Last reply Reply Quote 0
          • johnpoz
            johnpoz LAYER 8 Global Moderator last edited by

            Just reject your modems dhcp server 192.168.100 address... In the 10 some years been using pfsense, and cable modems I have never run into this issue.. The lease time that your modem should hand out from its 192.168.100 address pool should be really short.. So once it gets say a 192.168.100 address that should expire shortly and then it would get an IP from your ISP..

            An intelligent man is sometimes forced to be drunk to spend time with his fools
            If you get confused: Listen to the Music Play
            Please don't Chat/PM me for help, unless mod related
            SG-4860 23.01 | Lab VMs CE 2.6, 2.7

            T 1 Reply Last reply Reply Quote 1
            • N
              nkaminski last edited by nkaminski

              @xero9
              From the symptoms you describe it sounds like you are hitting this bug https://redmine.pfsense.org/issues/9267

              Specifically, what happens is that if the DHCP client times out and there is any cached lease, pfSense will use said IP regardless of if it is valid or not for the remaining lease time.

              However, if you are willing to compile dhclient and apply a patch using the pfSense system patch tool, it's pretty straightforward to fix this.

              Rejecting the lease from the modem as mentioned earlier will also likely work. However the caveat to be aware of is if your modem loses upstream link when pfSense tries to renew the DHCP lease (small chance but not zero) you may lose your connection.

              X 1 Reply Last reply Reply Quote 0
              • X
                xero9 @nkaminski last edited by

                @nkaminski This sounds like my issue exactly!

                So I'm no stranger to applying patches to file and re-compiling in say a Linux environment, but are there instructions on how I do this under pfSense? Is there a site with some documentation I can read? Thanks!

                N 1 Reply Last reply Reply Quote 0
                • e4ch
                  e4ch last edited by

                  fyi: see also this thread for a workaround
                  https://forum.netgate.com/topic/127403/auto-renew-dhcp-after-outage

                  1 Reply Last reply Reply Quote 1
                  • N
                    nkaminski @xero9 last edited by

                    @xero9

                    My recommendation if you are new to building FreeBSD would be to prepare a "vanilla" FreeBSD 11.2 system/VM and then follow https://www.freebsd.org/doc/handbook/makeworld.html to verify you can build FreeBSD from source successfully. You don't need to actually install, just make sure you can successfully complete the process leading up to such.

                    Once you confident with building the unmodified source, apply the dhclient patch with arguments '-p1' from the referenced pfSense bug ticket to /usr/src and rerun make on your build host.

                    Then all you will need to do is copy the dhclient binary across to your pfSense host, reboot, apply the dhclient-script patch using the pfSense "system patches" package and you should be good.

                    Do also keep in mind that pfSense updates overwrite /sbin, therefore in my case I created a /patch folder containing a copy of the patched dhclient so that I can copy it into place after updates.

                    1 Reply Last reply Reply Quote 0
                    • T
                      timboau 0 @johnpoz last edited by

                      @johnpoz The specific problem we have here in Australia with NBN in particular is as follows:

                      After a power outage both the modem and pfsense reboot. (modem is a VDSL type)
                      pfsense is much faster at rebooting than the Modem is to sync up and allow pass through for the DHCP request:
                      NBN / FTTN Modem in passthrough mode. (so in this case its not the modem giving out a local DHCP addresss)

                      Pfsense sees the ethernet WAN port come up - then requests a DHCP doesnt get it (modem stull doesnt have sync) and seems to give up and marks the port N/A and stops trying.

                      if at this stage you reboot pfsense its often OK
                      unplug/replug the WAN ethernet cable its often OK
                      WAN - release / reacquire a DHCP lease sometimes works.

                      Gertjan 1 Reply Last reply Reply Quote 0
                      • Gertjan
                        Gertjan @timboau 0 last edited by

                        @timboau-0 said in DHCP Client Issue:

                        the specific problem we have here in Australia

                        Bad news, and good news : this problem is known all over the planet.
                        Instead of using Interfaces > WAN > "Reject leases from", go one line lower, check out what "Protocol timing" can do for you, add a 'delay' that works for you.

                        No "help me" PM's please. Use the forum.

                        T 1 Reply Last reply Reply Quote 0
                        • T
                          timboau 0 @Gertjan last edited by

                          @Gertjan
                          Thanks, I'll investigate and see how that goes - although I don't think its really addressing the root cause of the problem.

                          While the delay function might work in this exact scenario I still don't feel a once of delay is the correct way to fix this problem. Sometime Sync can take longer than expected for example.

                          I would think if the WAN has a 0.0.0.0 or N/A IP address and set to DHCP it should be continually trying to obtain a valid IP address.

                          Gertjan e4ch N 3 Replies Last reply Reply Quote 0
                          • Gertjan
                            Gertjan @timboau 0 last edited by

                            @timboau-0 said in DHCP Client Issue:

                            I would think if the WAN has a 0.0.0.0 or N/A IP address and set to DHCP it should be continually trying to obtain a valid IP address.

                            And thus hammering that WAN interface (network, because it's a broadcast) until the end of times ? That couldn't be the good default DHCP client behaviour neither.
                            It's a classic issue : on a network, the DHCP server should be running before clients are activated.

                            What often happens is that the modem, slower as pfSense to start up, is handing over a LAN type, aka RFC 1918, for local management. Not good neither.

                            No "help me" PM's please. Use the forum.

                            1 Reply Last reply Reply Quote 0
                            • e4ch
                              e4ch @timboau 0 last edited by

                              @timboau-0 Keep in mind that this is a bug (see links above). If you don't want to use the scripts, then wait for the release 2.5.0, which will likely include the fix.

                              1 Reply Last reply Reply Quote 0
                              • N
                                nkaminski @timboau 0 last edited by

                                @timboau-0 Exactly. The case you describe :"if the WAN has a 0.0.0.0 or N/A IP address and is set to DHCP it should be continually be trying to obtain a valid IP address" is exactly the behavior that this bug prevents.

                                Specifically, once dhclient times out, it will not retry for a potentially very long time; if you can share the dhclient logs (real IPs not necessary) from when you see the IP loss, we will be able to tell if this bug is indeed being triggered.

                                Hammering the WAN link with a large quantity of DHCP requests is also indeed bad, hence the implementation of an exponential backoff algorithm to mitigate this.

                                1 Reply Last reply Reply Quote 0
                                • First post
                                  Last post