Second DHCP range stops leasing. Please Help!



  • 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.



  • @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?



  • 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.



  • 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?



  • @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.


  • 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.



  • @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.



  • 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 )



  • 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



  • 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



  • @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.



  • 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



  • @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.


  • 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.



  • 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


Log in to reply