Messages

Just to close this off ...

With the changes above I was still not able to assign my device 192.168.7.24 eventhough its lease had expired and the device was clearly defined to that ip address based on its mac address in the hosts table.

However, after additional trial and error I finally found what was blocking it.

On the OPNSense - Interace window related to this device, the is a field entitled IPv4 Address.
I had it populated with:

192.168.7.24 /24

In any case, I changed it to:
192.168.7.1 /24

and, Bob's your uncle, after I rebooted my device it picked up the IP address 192.168.7.24

Mystery solved.

If I'm following that sequence right, it sounds like your broke something (probably your dnsmasq DHCP config) before resetting the ISC DHCP config (and maybe the clients were still clinging onto old leases, or something). Maybe you could try resetting the ISC DHCP config again, and hopefully dnsmasq is still functional from the 2-days-ago snapshot.....

Good news

after following that suggestiong and a reboot, the system came back up with the internet fully working, also the offending entry was now gone

Bad news

I still can not assign 192.168.7.24 to that device

Good news

Originally the range on the interface I am using was 192.168.7.24 - 192.168.7.25 as I only had one device I was using on it at a time.
I thought perhaps OPNSense was doing something / locking / who knows what with that first address and why I was not able to assign it.
In any case, I've now changed the range to 192.168.7.1 - 192.168.7.100 and after that my device got a new dynamic address of 192.168.7.72.
I've now added a static entry to flip it to 192.168.7.24 - but will have to wait for the lease to expire - after which time I'm hoping it will be all good once again.

Also, as an asided, I'm thinking the one potentially non-benign change I had made over the last two days was checking the option 'This interface does not require an intermediate system to act as a gateway' which may have explained some of the issues with restoring from the most recent snapshop - but in any case I don't care as the one from two days ago did the trick - underlining the importance of taking snapshots!

Thanks all very much for your help.

Well I have a mix of good news and bad news:

Good news

I did a reset of via System: Configuration: Defaults - Components of Services: ISC DHCPv4 [legacy] [dhcpd] and rebooted OPNSense
Using System - Configuration - Backup I download my new configuration
I looked at it and the offending entry as well as many others were removed!

Bad news

I lost Internet access through my entire network and when I rebooted my device which I am trying to have 192.168.7.24 assigned to it would not establish an IPv4 connection.

Good news

Prior to the making the  System: Configuration reset I had created a snapshot

Bad news

I restored from that snapshot and rebooted; the internet was still down and my device was still not getting an IPv4 address.

Good news

I had made a snapshot 2 days ago, I restored from that and rebooted; the internet was back up again and my device got an ip adress albeit the one it had before all this started.

Bad news

Using System - Configuration - Backup I download my restored configuration
I looked at it and the offending entry was again there (as expected)
So I'm back to square one - however, learned something new as I had never actually done a snapshot recovery before.

Any other ides?

What exactly should I reset via "System: Configuration: Defaults - Components tab"?
I don't see ISC DHCP listed.

I am using dnsmasq dns & dhcp; having migraged to it several months ago when the prior way of doing this was being obsoleted. 

Thanks for this Patrick,

However, for clarification, by this I assume you mean to check the option on the interface entitled:
"This interface does not require an intermediate system to act as a gateway"

Which I did, followed by a save and apply, followed by another backup of my settings.
However, when I looked in them the same entry as shown in my original post was there.
```
    <opt2>
      <gateway>192.168.7.1</gateway>
      <ddnsdomainalgorithm>hmac-md5</ddnsdomainalgorithm>
      <numberoptions>
        <item/>
      </numberoptions>
      <range>
        <from>192.168.7.24</from>
        <to>192.168.7.24</to>
      </range>
      <winsserver/>
      <dnsserver>192.168.7.1</dnsserver>
      <ntpserver/>
      <staticmap>
        <mac>24:0a:c4:26:9e:43</mac>
        <ipaddr>192.168.7.24</ipaddr>
        <hostname>MasterClock</hostname>
        <descr>MasterClock</descr>
        <arp_table_static_entry>1</arp_table_static_entry>
        <winsserver/>
        <dnsserver/>
        <ntpserver/>
      </staticmap>
    </opt2>
```

Will these now be ignored? 

I'm asking as I would otherwise just test it, but I have to wait for mid morning tomorrow for the existing lease to expire.

Thanks again for your help.

I'm having trouble assigning a new device to an old ip address (I don't think it is the dnsmasq lease expiry issue - rather something else).

What I'm trying to do is to get a new device to come in and be assigned the address 192.168.7.24 which had previousily been assigned.
I waited until it had expired in the lease table, and then plugged in the new device - however it would not get the address I had wanted to spite me having already it defined in the dnsmasq host table (by its MAC) to be assigned to 192.168.7.24

I can get it assinged to 192.168.7.25 - but with that I get odd behaviours.

For example, the device is plugged directly into the OPNSense box's opt2 interface.  There is only one device plugged into that interface - but regardless with that one device plugged in I can ping both 192.168.7.24 and 192.168.7.25. 

As I'm using this device in conjunction with OPNSense's Time Service; I've tried stopping that server and turning it on at various points in my experementation to get this to work - just incase the time service has a hold on the IP address some how??

Also, oddly, while 192.168.7.24 no longer shows up in the lease table or the host table, I backed up my configuration and looked inside the back up file to find this (I just have no idea where to delete it from):

```
    <opt2>
      <gateway>192.168.7.1</gateway>
      <ddnsdomainalgorithm>hmac-md5</ddnsdomainalgorithm>
      <numberoptions>
        <item/>
      </numberoptions>
      <range>
        <from>192.168.7.24</from>
        <to>192.168.7.24</to>
      </range>
      <winsserver/>
      <dnsserver>192.168.7.1</dnsserver>
      <ntpserver/>
      <staticmap>
        <mac>24:0a:c4:26:9e:43</mac>
        <ipaddr>192.168.7.24</ipaddr>
        <hostname>MasterClock</hostname>
        <descr>MasterClock</descr>
        <arp_table_static_entry>1</arp_table_static_entry>
        <winsserver/>
        <dnsserver/>
        <ntpserver/>
      </staticmap>
    </opt2>
```
edit: I thought maybe if I could delete / clear the above I could get it to work - but can't seem to find how to do that.

edit: I should note I am running OPNsense 26.7.2_2-amd64 ; FreeBSD 15.1-RELEASE-p2 ; OpenSSL 3.5.7

@Monviech thank you for the update and the explanation.

Is this still on the table? 

I ran into a situation yesterady that I needed to reset which device was using a specific ip address and could not;  In short, I'm using the Network Time Service with OPNSense and have attached to my system a stratum 1 time server at IP address 192.168.7.24. Various devices on the network reference this IP address specifically.  The device I am now using is a replacement to the old one and has a different different mac.

With the old way of doing things this was simple, but with dnsmasq not giving up the on the lease on the old device, even after I restart the dnsmasq service, it seems I'm stuck with a misconfigured network until the old lease expires later today.

Some sort of delete button on the old lease would be very helpful.

thank you - it is now gone!

Recently I upgraded to OPNSense 26.1 and with that upgrade migrated to dnsmasq dns and dhcp - and everything is working fine.

However, in my list of firmware plugins I notice I have this:

os-isc-dhcp (installed)   1.0_3   277KiB   2   OPNsense   ISC DHCPv4/v6 server

Is this still needed or can it be removed without impact to how things work?

Thank you for your time and insights.  This is a well over my paid grade, so I really do appreciate your help.  I'll poke around a little more on this and may open it on github as potential bug.  However, for now I've got my program up and running, just had to assign a static ip address to the device running it. 

Thing is it took several days until I stumbled on this work work around.  However, perhaps someone else reading this thread in the future will be able to save some time because of it. 

Again, with thanks for your time and insights!

Well, I change my project's code to reference only 1 NPT Server (as shown below)

configTime(GMT_OFFSET_SEC, DAY_LIGHT_OFFSET_SEC, NTP_SERVER1);

and point directly to the ip address of my esp32 time server used by OPNSense.

However, I got the same results:

If the client is assigned a dynamic IP address it does not get the time from the time server.

If the client is assigned a status IP address it does get the time from the time server.

Well of course you are right! :-)

I had been thinking of my ntp server as the Network Time Service running on OPNSense - i.e. the ip address of the OPNSense box itself - which as I understand it intercepts calls to, for example, pool.ntp.org, and responds to the device itself.

Hi,

Thanks for your comments.

Regarding: Obviously, you set the NTP servers in your code, so your client does not use DHCP assignments.

That's not exactly how it works, if you look at the example from my earlier post here: https://wokwi.com/projects/420011361310192641 you will notice that all that is done is a wifi connection.  The NTP request, travels over UDP, and I assume is generally broadcast and that is how the NTP sever pick up on the request.  I also assume that the NTP server gets the source IP address from the UPD packet and that is how it know to which device it needs to respond to (if it itself also doesn't do a general broadcast). In any case I am no expert on how NTP Servers work, but that is my educated guess as the client doesn't configure the NTP server's address.

Again, this works fine when the client is connected with a static address, but with a dynamic one.