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

    WAN dhcp (dhclient) going to wrong IP

    Scheduled Pinned Locked Moved DHCP and DNS
    5 Posts 3 Posters 1.8k Views
    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
      bri189
      last edited by

      Occassionally my WAN drops (don't know why, not important right now), if dhclient is doing job correctly though it should renew lease with ISP and be seamless.

      Instead what is happening is it is trying to renew with 192.168.100.1 - no idea what this is; thinking maybe the ISP 'guest wireless' that I have no control over and can't turn off.

      Anyway, I have configured WAN already to reject lease from 192.168.100.1 and from logs it appears to be trying to do that, but sometimes it gives up and only way to get my true IP from ISP is to either reset the ISP modem or log into pfSense (requires being at home) and manually releasing/renewing.  Curious if something I'm blocking inbound is causing WAN address to not renew correctly as well - on old Linksys my WAN side never had these type of issue, but that's a side of the network I don't know very well.

      I've now set up a floating rule to block (UDP 67/68) outbound from WAN to 192.168.100.1, but not sure this is the best way to address and not sure if pfSense still won't give up.  Is there a way I can force pfSense to just stop this from happening or is there something I might have configured wrong on WAN that I need to look at?

      Relevant logs with actual IP address from ISP removed and replace with 70.1.15.15:

      Jul 27 11:00:25 dhclient ifconfig em0 inet 70.1.15.15 netmask 255.255.254.0 broadcast 255.255.255.255
      Jul 27 11:00:25 dhclient Starting add_new_address()
      Jul 27 11:00:25 dhclient TIMEOUT
      Jul 27 11:00:25 dhclient 44743 Trying recorded lease 70.1.15.15
      Jul 27 11:00:25 dhclient 44743 No DHCPOFFERS received.
      Jul 27 11:00:18 dhclient 44743 DHCPOFFER from 192.168.100.1 rejected.
      Jul 27 11:00:18 dhclient 44743 DHCPDISCOVER on em0 to 255.255.255.255 port 67 interval 7
      Jul 27 11:00:05 dhclient 44743 DHCPOFFER from 192.168.100.1 rejected.
      Jul 27 11:00:05 dhclient 44743 DHCPDISCOVER on em0 to 255.255.255.255 port 67 interval 13
      Jul 27 10:59:54 dhclient 44743 DHCPOFFER from 192.168.100.1 rejected.
      Jul 27 10:59:54 dhclient 44743 DHCPDISCOVER on em0 to 255.255.255.255 port 67 interval 11
      Jul 27 10:59:43 dhclient 44743 DHCPOFFER from 192.168.100.1 rejected.
      Jul 27 10:59:43 dhclient 44743 DHCPDISCOVER on em0 to 255.255.255.255 port 67 interval 11
      Jul 27 10:59:33 dhclient 44743 DHCPOFFER from 192.168.100.1 rejected.
      Jul 27 10:59:33 dhclient 44743 DHCPDISCOVER on em0 to 255.255.255.255 port 67 interval 10
      Jul 27 10:59:29 dhclient 44743 DHCPOFFER from 192.168.100.1 rejected.
      Jul 27 10:59:29 dhclient 44743 DHCPDISCOVER on em0 to 255.255.255.255 port 67 interval 4
      Jul 27 10:59:27 dhclient 44743 DHCPOFFER from 192.168.100.1 rejected.
      Jul 27 10:59:27 dhclient 44743 DHCPDISCOVER on em0 to 255.255.255.255 port 67 interval 2
      Jul 27 10:59:25 dhclient 44743 DHCPOFFER from 192.168.100.1 rejected.
      Jul 27 10:59:25 dhclient 44743 DHCPDISCOVER on em0 to 255.255.255.255 port 67 interval 2
      Jul 27 10:59:24 dhclient 44743 DHCPOFFER from 192.168.100.1 rejected.
      Jul 27 10:59:24 dhclient 44743 DHCPDISCOVER on em0 to 255.255.255.255 port 67 interval 1
      Jul 27 10:59:15 dhclient 44743 DHCPNACK from 192.168.100.1 rejected.
      Jul 27 10:59:15 dhclient 44743 DHCPREQUEST on em0 to 255.255.255.255 port 67
      Jul 27 10:59:10 dhclient 44743 DHCPNACK from 192.168.100.1 rejected.
      Jul 27 10:59:10 dhclient 44743 DHCPREQUEST on em0 to 255.255.255.255 port 67
      Jul 27 10:59:08 dhclient 44743 DHCPNACK from 192.168.100.1 rejected.
      Jul 27 10:59:08 dhclient 44743 DHCPREQUEST on em0 to 255.255.255.255 port 67
      Jul 27 10:59:06 dhclient 44743 DHCPNACK from 192.168.100.1 rejected.
      Jul 27 10:59:06 dhclient 44743 DHCPREQUEST on em0 to 255.255.255.255 port 67
      Jul 27 10:59:06 dhclient PREINIT
      Jul 27 10:59:02 dhclient 23360 exiting.
      Jul 27 10:59:02 dhclient 23360 connection closed
      Jul 27 10:59:01 dhclient 56511 em0 link state up -> down
      Jul 27 10:17:40 dhclient 22602 bound to 70.1.15.15 – renewal in 92553 seconds.

      1 Reply Last reply Reply Quote 0
      • C
        cmb
        last edited by

        192.168.100.1 is almost certainly your modem, that's the default IP they often use in those cases. If the modem loses uplink, it tries to assign you an IP to be able to communicate with it. That's not it going to any IP, that's just that your modem is replying from that IP. Problem is your modem or its connection to your provider.

        1 Reply Last reply Reply Quote 0
        • B
          bri189
          last edited by

          Thanks.

          Yeah I was able to confirm it's the ISP modem.  Popped 192.168.100.1 it into browser and there it is: "Motrolla Modem Configuration".  No login available but able to see DHCP turned on and no ability to turn it off.

          So there's nothing I really can do right?

          1 Reply Last reply Reply Quote 0
          • C
            cmb
            last edited by

            Nothing you can do.

            1 Reply Last reply Reply Quote 0
            • T
              ttabbal
              last edited by

              Is it possible to force it to retry sooner? 92553 seconds is over a day. I'm having a similar problem, and while we can blame the provider all we like, it's not going to help anything. If we can force it to retry sooner, regardless of the current lease timeout, it would likely fix it. Since a release/renew works, forcing dhclient to retry would likely get a lease from the DHCP server and everything would work fine again. I could likely hack it up with a cron job, but there should be a better way than that.

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