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

    Second DHCP range stops leasing. Please Help!

    DHCP and DNS
    6
    15
    9.3k
    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.
    • B
      BrandonKenny
      last edited by

      We have two DHCP ranges running off our pfsense, 192.168.0.0/24 and 192.168.2.0/24. On both ranges we have reserved all our users with there MAC addresses. We use the 192.168.2.0/24 for phone's, tablets and all our guest that come in. We never seem to have a problem with 192.168.0.0/24 but every now and then, 192.168.2.0/24 stops leasing out the DHCP addresses even if we have reserved devises, they no-longer get a IP from the DHCP server. The only way I have figured out how to fix the problem is to restart the firewall, but then every couple of weeks the problem returns. This is becoming a problem as people have to stop working will we do the restart.

      Is there a way to fix this problem permanently or even to fix it without a restart?
      ps: I have tried restarting the DHCP service.

      1 Reply Last reply Reply Quote 0
      • W
        wallabybob
        last edited by

        @BrandonKenny:

        We have two DHCP ranges running off our pfsense, 192.168.0.0/24 and 192.168.2.0/24.

        I presume these two ranges apply to two distinct interfaces. Is that correct?

        @BrandonKenny:

        On both ranges we have reserved all our users with there MAC addresses. We use the 192.168.2.0/24 for phone's, tablets and all our guest that come in. We never seem to have a problem with 192.168.0.0/24 but every now and then, 192.168.2.0/24 stops leasing out the DHCP addresses even if we have reserved devises, they no-longer get a IP from the DHCP server.

        Since all addresses have been reserved to specific MAC addresses there shouldn't be a problem due to there not being enough unassigned IP addresses for requests from "unregistered" MAC addresses. So I would guess the problem is a client not being able to renew a lease (or, based on information I have seen in other posts, a client apparently not seeing a DHCP lease renewal). Is there any pattern to this, for example not seen on iPads but seen on Android 2.1 devices?

        Have you looked in the DHCP server log (see Status -> System Logs, click on DHCP tab)? especially around the time of a device apparently not being assigned an IP address?

        1 Reply Last reply Reply Quote 0
        • W
          Waynedb
          last edited by

          Hi

          I work with Brandon, there is two interfaces one for each IP range.
          Apple devices does not get IP's from the 192.168.2.0/24 until we restart, then it works for a while.
          Android's always gets IP's.

          1 Reply Last reply Reply Quote 0
          • jahonixJ
            jahonix
            last edited by

            Surely I don't want to hijack this thread - "DHCP stops leasing" cought me.

            What pfSense version are you on?

            It was yesterday evening that my trusted 1.2.3 install stopped leasing on LAN IF. That is VLAN 1 out of 6 on the internal NIC.
            Wireless clients on a different VLAN (with separate IP range) still had a lease but started to drop as well.
            A reboot did not fix it.

            Since I was in a hurry I dropped in another hardware that was prepared for a client and still laying around.
            I was the last one in the office and didn't work on IT.

            Any ideas where to look and what for?

            1 Reply Last reply Reply Quote 0
            • W
              wallabybob
              last edited by

              @jahonix:

              Any ideas where to look and what for?

              1. DHCP log (see Status -> System Logs and click on DHCP tab, but I haven't run pfSense 1.2.3 for a long while so my memory might be stale.)
              2. Is the dhcp server still running? What is the output of pfSense shell command```
              ps ax | grep dhcpd

              
If the DHCP server is not running. you might be able to restart it by disabling then enabling it. If the DHCP server stopped you might find an explanation in the DHCP log or the system log.
              1 Reply Last reply Reply Quote 0
              • B
                BrandonKenny
                last edited by

                Clearing the DHCP logs did not work and the DHCP service is still running. Restarting the DHCP service does nothing.

                In the DHCP logs I can only see the error: no free leases.
                This is from my 192.168.0.0 range though. I have told the 192.168.0.0 range not to lease IP so this is not a problem. There are no error's regarding the 192.168.2.0 range which should be leasing IP's but isn't.

                1 Reply Last reply Reply Quote 0
                • W
                  wallabybob
                  last edited by

                  @BrandonKenny:

                  Clearing the DHCP logs did not work

                  I wouldn't expect it to do anything beyond clear the log.

                  @BrandonKenny:

                  In the DHCP logs I can only see the error: no free leases.

                  Please post an extract from the log showing about six lines before that report,the report and the next six lines.

                  Does the DHCP log show DHCP requests from devices that aren't getting leases? If the requests aren't in the DHCP log then you need to investigate why the DHCP server isn't seeing the requests. If the requests are recorded in the DHCP log then post the record of a request and the next six lines so we can what the DHCP server is doing with the request.

                  1 Reply Last reply Reply Quote 0
                  • M
                    mcdonste
                    last edited by

                    I have the same problem, alix board, latest version of pfsense. 2 DHCP services one on Wifi and one on LAN ( these are not bridged ). The Wifi DHCP logs nothing when macs and ipads try to connect to the wifi after a period of time. if the wifi does connect ( rare ) I get the following logs. LAN always works.

                    Aug 26 19:00:13    dhcpd: DHCPREQUEST for 192.168.7.11 from 84:38:35:66:0f:10 via ath0_wlan0: wrong network.
                    Aug 26 19:00:13    dhcpd: DHCPNAK on 192.168.7.11 to 84:38:35:66:0f:10 via ath0_wlan0
                    Aug 26 19:00:15    dhcpd: DHCPREQUEST for 192.168.7.11 from 84:38:35:66:0f:10 via ath0_wlan0: wrong network.
                    Aug 26 19:00:15    dhcpd: DHCPNAK on 192.168.7.11 to 84:38:35:66:0f:10 via ath0_wlan0
                    Aug 26 19:00:15    dhcpd: DHCPDISCOVER from 84:38:35:66:0f:10 via ath0_wlan0
                    Aug 26 19:00:16    dhcpd: unexpected ICMP Echo Reply from 8.8.8.8
                    Aug 26 19:00:16    dhcpd: unexpected ICMP Echo Reply from 8.8.4.4
                    Aug 26 19:00:16    dhcpd: DHCPOFFER on 192.168.23.12 to 84:38:35:66:0f:10 via ath0_wlan0
                    Aug 26 19:00:17    dhcpd: DHCPREQUEST for 192.168.23.12 (192.168.23.1) from 84:38:35:66:0f:10 via ath0_wlan0
                    Aug 26 19:00:17    dhcpd: DHCPACK on 192.168.23.12 to 84:38:35:66:0f:10 via ath0_wlan0

                    The "wrong network" message is due to the mac previously being connected to another wifi service I have set up

                    The network looks like:

                    LAN 192.168.22.1
                    WIFI 192.168.23.1
                    WAN1 DHCP to router 192.168.4.1 connected at ADSL
                    WAN2 DHCP to wifi router 192.168.7.1 connected to Cable
                    fail over and load balance enabled ( works great from LAN )

                    1 Reply Last reply Reply Quote 0
                    • M
                      mcdonste
                      last edited by

                      Think I found my problem, looks like the DHCP requests are being serviced upstream by 169.254 and only occasionally by 192.168.23. 169.254 is defiantly not in my setup.  The 192.168.4 and 192.169.7 are 2 other wifi points and these work fine. The little sequence below is me switching between the three wifi points.

                      How do I stop what is ever on the internet service the DHCP request and make pfsense do the work???

                      wifi >> DHCP 192.168.23.1 = pfsense radio port 
                      LAN >> DHCP 192.168.22.1 = pfsense LAN port

                      pfsense WAN1 >> DHCP 192.168.4.1 = ADSL wifi modem router
                      pfsence WAN2 >> DHCP 129.168.11.1 = Cable wifi modem rouer

                      Why do the connects to the wifi modem routers always work with do interference from upstream systems??

                      Why does the LAN connects ( none hear ) always work

                      Aug 26 18:51:29 stevens-macbook-air.local configd[17]: network changed: v4(en0-:169.254.150.172) DNS* Proxy- SMB
                      Aug 26 18:51:29 Stevens-MacBook-Air.local configd[17]: setting hostname to "Stevens-MacBook-Air.local"
                      Aug 26 18:51:34 Stevens-MacBook-Air.local configd[17]: network changed: v4(en0+:192.168.4.15) DNS+ Proxy+ SMB
                      Aug 26 18:51:34 Stevens-MacBook-Air.local configd[17]: network changed: v4(en0!:192.168.4.15) DNS Proxy SMB
                      Aug 26 18:52:01 Stevens-MacBook-Air.local configd[17]: network changed: v4(en0-:192.168.4.15) DNS- Proxy- SMB
                      Aug 26 18:52:19 Stevens-MacBook-Air.local configd[17]: subnet_route: write routing socket failed, Network is unreachable
                      Aug 26 18:52:21 Stevens-MacBook-Air.local configd[17]: network changed: v4(en0+:169.254.243.15) DNS* Proxy+ SMB
                      Aug 26 18:52:21 Stevens-MacBook-Air.local configd[17]: network changed: v4(en0:169.254.243.15) DNS Proxy SMB
                      Aug 26 18:52:23 stevens-macbook-air.local configd[17]: setting hostname to "stevens-macbook-air.local"
                      Aug 26 18:52:37 stevens-macbook-air.local configd[17]: network changed: v4(en0-:169.254.243.15) DNS* Proxy- SMB
                      Aug 26 18:52:37 Stevens-MacBook-Air.local configd[17]: setting hostname to "Stevens-MacBook-Air.local"
                      Aug 26 18:53:08 Stevens-MacBook-Air.local configd[17]: subnet_route: write routing socket failed, Network is unreachable
                      Aug 26 18:53:10 Stevens-MacBook-Air.local configd[17]: network changed: v4(en0+:169.254.5.16) DNS* Proxy+ SMB
                      Aug 26 18:53:10 Stevens-MacBook-Air.local configd[17]: network changed: v4(en0:169.254.5.16) DNS Proxy SMB
                      Aug 26 18:53:12 stevens-macbook-air.local configd[17]: setting hostname to "stevens-macbook-air.local"
                      Aug 26 18:53:22 stevens-macbook-air.local configd[17]: LINKLOCAL en0: parent has no IP
                      Aug 26 18:53:22 stevens-macbook-air.local configd[17]: LINKLOCAL en0: parent has no IP
                      Aug 26 18:53:22 stevens-macbook-air.local configd[17]: network changed: v4(en0-:169.254.5.16) DNS* Proxy- SMB
                      Aug 26 18:53:22 Stevens-MacBook-Air.local configd[17]: setting hostname to "Stevens-MacBook-Air.local"
                      Aug 26 18:53:27 Stevens-MacBook-Air.local configd[17]: network changed: v4(en0+:192.168.7.11) DNS+ Proxy+ SMB
                      Aug 26 18:53:27 Stevens-MacBook-Air.local configd[17]: network changed: v4(en0!:192.168.7.11) DNS Proxy SMB
                      Aug 26 19:00:13 Stevens-MacBook-Air.local configd[17]: LINKLOCAL en0: parent has no IP
                      Aug 26 19:00:13 Stevens-MacBook-Air.local configd[17]: network changed: v4(en0-:192.168.7.11) DNS- Proxy- SMB
                      Aug 26 19:00:19 Stevens-MacBook-Air.local configd[17]: network changed: v4(en0+:192.168.23.12) DNS+ Proxy+ SMB
                      Aug 26 19:00:19 Stevens-MacBook-Air.local configd[17]: network changed: v4(en0!:192.168.23.12) DNS Proxy SMB
                      Aug 26 19:27:32 Stevens-MacBook-Air.local configd[17]: network changed: v4(en0-:192.168.23.12) DNS- Proxy- SMB
                      Aug 26 19:27:59 Stevens-MacBook-Air.local configd[17]: subnet_route: write routing socket failed, Network is unreachable
                      Aug 26 19:28:01 Stevens-MacBook-Air.local configd[17]: network changed: v4(en0+:169.254.35.51) DNS* Proxy+ SMB
                      Aug 26 19:28:01 Stevens-MacBook-Air.local configd[17]: network changed: v4(en0:169.254.35.51) DNS Proxy SMB

                      1 Reply Last reply Reply Quote 0
                      • P
                        phil.davis
                        last edited by

                        Think I found my problem, looks like the DHCP requests are being serviced upstream by 169.254 and only occasionally by 192.168.23. 169.254 is defiantly not in my setup.

                        Without looking at all the detail here, I will jump in with 1 comment. 169.254.0.0/16 are reserved as link local address. Various network stacks (e.g. Windows) will allocate themselves one of these addresses when they timeout waiting for DHCP.
                        You don't have a rogue DHCP server anywhere giving these out - although it could be fun to set one up on an unsuspecting network and hand out addresses in this range :)
                        See: http://en.wikipedia.org/wiki/Private_network

                        As the Greek philosopher Isosceles used to say, "There are 3 sides to every triangle."
                        If I helped you, then help someone else - buy someone a gift from the INF catalog http://secure.inf.org/gifts/usd/

                        1 Reply Last reply Reply Quote 0
                        • W
                          wallabybob
                          last edited by

                          @mcdonste:

                          I have the same problem, alix board, latest version of pfsense. 2 DHCP services one on Wifi and one on LAN ( these are not bridged ). The Wifi DHCP logs nothing when macs and ipads try to connect to the wifi after a period of time. if the wifi does connect ( rare ) I get the following logs. LAN always works.

                          Aug 26 19:00:13    dhcpd: DHCPREQUEST for 192.168.7.11 from 84:38:35:66:0f:10 via ath0_wlan0: wrong network.

                          I presume ath_wlan0 is your WiFi network. Why is the system with MAC address 84:38:35:66:0f:10 trying to get IP address 192.168.7.11, an IP address on your WAN2 network? How did the system with the reported MAC address move from the WAN2 network to your WiFi network?

                          What is the system with the reported MAC address?

                          Perhaps you have a configuration error.

                          1 Reply Last reply Reply Quote 0
                          • M
                            mcdonste
                            last edited by

                            Thanks for the help so far, I can see the DHCP calls being blocked in the firewall.

                            Aug 31 05:09:50 WAN   192.168.4.6:61392   224.0.0.1:8612 UDP
                            block
                            Aug 31 05:09:56 ath0_wlan0   0.0.0.0:68   255.255.255.255:67 UDP
                            block
                            Aug 31 05:09:59 WAN   192.168.4.6:49950   192.168.4.255:8612 UDP
                            block
                            Aug 31 05:09:59 WAN   192.168.4.6:56508   224.0.0.1:8612 UDP

                            Clicking on the block reason I get the following

                            The rule that triggered this action is:
                            @1 scrub on vr0 all fragment reassemble
                            @1 block drop in log all label "Default deny rule"

                            is the issue that if the client calls with 0.0.0.0 as its ip then it gets blocked but if it calls with an ip it got from previous lease then it does work??

                            here is one that did work

                            dhcpd: DHCPREQUEST for 192.168.4.15 from 84:38:35:66:0f:10 via ath0_wlan1: unknown lease 192.168.4.15.
                            Aug 31 15:14:19 dhcpd: DHCPREQUEST for 192.168.4.15 from 84:38:35:66:0f:10 via ath0_wlan1: unknown lease 192.168.4.15.
                            Aug 31 15:14:21 dhcpd: DHCPREQUEST for 192.168.4.15 from 84:38:35:66:0f:10 via ath0_wlan1: unknown lease 192.168.4.15.
                            Aug 31 15:14:26 dhcpd: DHCPDISCOVER from 84:38:35:66:0f:10 via ath0_wlan1
                            Aug 31 15:14:26 dhcpd: unexpected ICMP Echo Reply from 8.8.8.8
                            Aug 31 15:14:26 dhcpd: unexpected ICMP Echo Reply from 8.8.4.4
                            Aug 31 15:14:27 dhcpd: DHCPOFFER on 192.168.23.12 to 84:38:35:66:0f:10 via ath0_wlan1
                            Aug 31 15:14:28 dhcpd: DHCPREQUEST for 192.168.23.12 (192.168.23.1) from 84:38:35:66:0f:10 via ath0_wlan1
                            Aug 31 15:14:28 dhcpd: DHCPACK on 192.168.23.12 to 84:38:35:66:0f:10 via ath0_wlan1

                            How do I stop the wifi interface blocking calls from 0.0.0.0

                            1 Reply Last reply Reply Quote 0
                            • W
                              wallabybob
                              last edited by

                              @mcdonste:

                              Thanks for the help so far, I can see the DHCP calls being blocked in the firewall.

                              Aug 31 05:09:56 ath0_wlan0   0.0.0.0:68   255.255.255.255:67 UDP
                              block

                              @mcdonste:

                              here is one that did work

                              dhcpd: DHCPREQUEST for 192.168.4.15 from 84:38:35:66:0f:10 via ath0_wlan1: unknown lease 192.168.4.15.

                              How do I stop the wifi interface blocking calls from 0.0.0.0

                              The one that works is received on interface ath0_wlan1 whilst the one that is blocked was received on interface ath_wlan0. It appears you have multiple WiFinterfaces  on the one physical interface ath0. That is valid but is it what you intended? And should DHCP server be enabled on ath0-wlan0?

                              Please post the output of pfSense shell command```
                              /etc/rc.banner

                              
If you intend to have multiple WiFi interfaces on the same physical interface then you have will need to add suitable firewall rules to interface ath0_wlan0.

There is still something weird going on:
@mcdonste:

> Aug 31 15:14:19 dhcpd: DHCPREQUEST for 192.168.4.15 from 84:38:35:66:0f:10 via ath0_wlan1: unknown lease 192.168.4.15.
> Aug 31 15:14:21 dhcpd: DHCPREQUEST for 192.168.4.15 from 84:38:35:66:0f:10 via ath0_wlan1: unknown lease 192.168.4.15.
> Aug 31 15:14:26 dhcpd: DHCPDISCOVER from 84:38:35:66:0f:10 via ath0_wlan1
> Aug 31 15:14:26 dhcpd: unexpected ICMP Echo Reply from 8.8.8.8
> Aug 31 15:14:26 dhcpd: unexpected ICMP Echo Reply from 8.8.4.4
> Aug 31 15:14:27 dhcpd: DHCPOFFER on 192.168.23.12 to 84:38:35:66:0f:10 via ath0_wlan1
> Aug 31 15:14:28 dhcpd: DHCPREQUEST for 192.168.23.12 (192.168.23.1) from 84:38:35:66:0f:10 via ath0_wlan1
> Aug 31 15:14:28 dhcpd: DHCPACK on 192.168.23.12 to 84:38:35:66:0f:10 via ath0_wlan1

Why is the machine with MAC address 84:38:35:66:0f:10 migrating from the 192.168.4.0/x network to the 192.168.23.0/x network?

You have mentioned only one WiFi interface. Are the WAN1 and WAN2 pfSense interfaces WiFi interfaces? If not, have you done something to the machine with MAC address 84:38:35:66:0f:10 so that it uses the same MAC address on its wired and wireless interfaces?

Your earlier post
@mcdonste:

> The Wifi DHCP logs nothing when macs and ipads try to connect to the wifi after a period of time.

and the newly provided new data leads me to wonder if the ADSL WiFi modem is still acting as a WiFi access point and the client is sometimes getting an IP address from it and hence the DHCP request is not getting logged in the pfSense DHCP log.
                              1 Reply Last reply Reply Quote 0
                              • P
                                phil.davis
                                last edited by

                                When you have DHCP enabled on an interface, pfSense writes rules to allow the necessary DHCP traffic, like:

                                # allow access to DHCP server on LAN1
pass in quick on $LAN1 proto udp from any port = 68 to 255.255.255.255 port = 67 label "allow access to DHCP server"
pass in quick on $LAN1 proto udp from any port = 68 to 10.99.1.250 port = 67 label "allow access to DHCP server"
pass out quick on $LAN1 proto udp from 10.99.1.250 port = 67 to any port = 68 label "allow access to DHCP server"

                                You can look in /tmp/rules.debug to see if these are there or missing on the interfaces you expect to have DHCP. That might help you track down where the problem is, why some DHCP gets blocked.

                                As the Greek philosopher Isosceles used to say, "There are 3 sides to every triangle."
                                If I helped you, then help someone else - buy someone a gift from the INF catalog http://secure.inf.org/gifts/usd/

                                1 Reply Last reply Reply Quote 0
                                • M
                                  mcdonste
                                  last edited by

                                  All fixed, thanks, there was some good tips here.

                                  I had configured the alix radio to have a clone interface and I left that disabled. problem was that the firewall still blocked that interface. You must either fully config with IP, DHCP, firewall rules etc or completely remove the clone. The randomness must have been the clone grabbing the packets with sometimes the main WIFI getting them

                                  also had to add a firewall rule to allow UDP 68/67 from 0000 to 255.255.255.255, strange as I didn't need to do that on the LAN.

                                  I don't think this is the original posters problem, problem sounded the same but in the end mine was specific to wifi, not the second interface

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