Messages

It wasn't DNS, but you put me on the right path! I also configured to redirect all clients to get their NTP time from OPNsense and that was done very near the time the Telo went offline. I disabled that rule and within a minute or so, the Telo went online.

I think the DNS redirect is OK but I will check that my rule is working correctly and fix if not, and then I'll know if that is also a problem for the Telo.

Thank you so much for your insight. Marking this solved.

<rant>Ooma support levels 1 and 2 never ever mentioned any hardcoded and required servers, be them time or DNS or whatever. Not once. None of their tests and reports showed any failed connections to any time or DNS servers, all passed. Grrrrr.</rant>

telo needs to be able to send DNS requests to their own servers

Thank you for this observation. I am rerouting all DNS requests to OPNsense, to force all clients to use only the DNS servers I've configured. So yes, the Telo is making DNS queries but they are going to my DNS servers and not any hard-coded ones Telo may be requesting.

I did make this change, to have all DNS handled by OPNsense, somewhere near the time the Telo stopped connecting. I thought I had verified the Telo was still working, but perhaps it was just residual and soon wasn't. I will test this. Hopefully this is all that's wrong and I have a spare Telo.

My Ooma Telo VOIP device (I'm a home user, this is residential service for my home phone) stopped connecting out to Ooma's servers on or about January 16th (about 2 1/2 weeks ago). It has been working for the past couple of years on the same hardware and OPNsense.

I was on 25.7 with all updates at the time it stopped working. But I just upgraded to 26.1 and it's still happening, so looking for help on this version.

A few things happened on or about the 16th:

1. ISP upgraded service in my area around that time
2. OPNsense had updates around that time
3. I migrated from ISC to DNSMasq around that time

I don't get calls every day and can't normally see the Telo device, it was another week when I realized I'd had no calls and saw the Telo was offline. Everything else had been working fine and stil is. On both 25.7 then and 26.1 now. AFAIK the Telo is the only issue.


Here's what I've done:

1. After checking basic things like swapping cables, power supply, DHCP lease gets assigned, troubleshooting using Telo's own config webpage, I called Ooma support and after several days of struggle with their various troubleshooting reports, Ooma says everything is good so if it isn't connecting the Telo is probably dead. They could not see it try to connect to their servers at all.

2. I bought a new Telo, called Ooma to activate it, we set it up, and it doesn't connect either.

3. I got referred to the next level Ooma support, they had me cable the new Telo inbetween the ISP's modem and OPNsense (it's on a protectli box), and it connected. It passes through all non Ooma traffic through. All was working again, albeit slowly, and my Ooma service was working.


I put the Telo back as a client on the LAN as it has been for years, and it doesn't connect. So I must've done something wrong on OPNsense I'm assuming, but I've no idea what since everything else works great.

I did want to try going back to ISC as a test, but on 26.1 I can't figure out how to add new devices? I don't have any plus signs anywhere to setup something new, at least not that I can see?

I do not use Unbound. DNSMasq uses the DNS servers I have under System area. I can see in the firewall logs everything is going to ones I specified and not my ISP's so I think that is working correctly. It is configured for all clients to forward all DNS queries to OPNsense (192.168.1.1) and let OPNsense handle the DNS, this way there is no client that can go around the DNS I've coded. (I think that's how it works.)

The Telo does make some DNS queries periodically, I can see that in the Firewall logs, they are going to OPNsense 192.168.1.1 just like all the other clients on my home network.

I did check that SIP ALG is still disabled and it is.

I have never done anything to use the Telo, just gave it a reserved IP address (to make it easier for me to find its setup page) and it has just worked all this time until now.

Oh, and my OPNsense configuration is very little more than the defaults, and nothing has been changed in a few years except for moving to DNSMasq. I've used a simple DNSMasq config with other routers in the past with no issue, I don't expect that's the problem now but I don't know for sure. I basically only use it to assign reserved leases and of course handle DHCP and DNS.


I am happy to try moving back to ISC for a test to narrow it down, but I need help figuring out how to add new devices. If there's anything else I can look at or try please let me know?

I don't know much about OPNsense, I'm just a home user who put it up pretty much by default a few years ago and tweaked a little over time, so please have some patience with my lack of know-how.

Thank you for any help and info on figuring this one out.

Kind regards.

As I said I don't mind if there is a canonical tool which there is.  I'll try to get it into the dnsmasq port. If it compiles and works it's good enough for the GUI button.

Thank you very much Franco.

For the server the IP is not assigned while it is still in use by the client.
So what happens when another client requests an IP address?

Maybe I'm not fully understanding your scenario, but it seems like what you describe is same or close to what happens when the client itself sends the DHCP release? (Meaning, the client we did the phony release for, still thinks it has the lease, but it doesn't actually have it, right? So another client can request it, same as if the release was genuine?)

The difference I see, one client thinks it has a lease and the other one doesn't. But in both cases (for different reasons) they both will experience DNS and internet connection issues until a new lease is assigned. I don't know what transpires to get a client, that didn't request a release itself, to pick up the a lease. I don't remember having any trouble in this area with past DNSMasq routers that I've used, but maybe I just didn't happen to experience any.

I don't mind integrating it if it works as a stand alone tool,

Could the lease tools be pushed to the appropriate directory? Then some of us could run from command line while waiting for GUI integration?

And while I was writing the above edit, I've had a reply from Simon Kelley:



In the dnsmasq source tree, there's a directory called

contrib/lease-tools

which contains what you're looking for.



Cheers,

Simon.



Would someone from OPNsense be able to take a look at this and see if it is possible to implement?

there is no way a given lease can be recalled

I'm not sure this is true. At Franco's suggestion I've sent a message to Simon Kelley, the developer of DNSMasq, as I searched his discussion list archives and found out he provided a script that could be attached to a button to remove a lease without stopping DNSMasq. This is what I likely used way back when since I don't remember having these issues. I've asked if this is still available or if he can recommend another method to settle this issue. I hope he'll respond to my query.

ETA: Here's a quote from Simon Kelley on DNSMasq discussion list:  "dhcp_release works by faking up a DHCP message as if it's coming from the DHCP client, which tells the server to release the lease."

This is exactly what I'm hoping for, a way to tell DNSMasq to perform all standard processes to release the lease.

As I mentioned I did read in github and others that the delete button is not coming (I am not the OP of this thread).

It's not about micromanaging... that's unfair and rather harsh. There are many uses for specific IP assignment and getting it all set up in one go, instead of breaking the task up because a lease won't expire for some times. Yes the client should be doing the release but not all devices do it.

I'm unclear why other DHCP products and even at least some past DNSMasq products were able to help here, but this one won't.

Hi Knebb,

I don't think you understand the issue, or I'm not understanding your suggestion.

Just to clarify, we are using DNSmasq not ISC. ISC already has a delete button.

The issue is the new client has *already* joined the wifi and now I am stuck dealing with that lease.
 
Yes the default lease could be very short. Refer my option #3, a temporary short lease. But that only works if I know when the client will join so I can be ahead of it.

A permanant short lease is possible but means most of my clients (dynamic) will constantly renew, maybe that works for the OP but it's not desirable for me. My default lease is intentionally long.

FWIW I have had several routers with DNSMasq in the past, though it has been some years ago.  This wasn't an issue with those implementations. I do not recall how they worked, I found my old notes and I don't have any steps written down. So it had to be something obvious like a delete button, or a device reboot caused a static assignment to replace any dynamic that existed - something along the lines of the router handling the issue, not me.

I am in similar situation and hoping for a straightforward, clean solution.

I have some devices I need a reserved DHCP address assigned. The wifi mac is not printed anywhere, I have to connect to ethernet or wifi first to get that. I set up a reserved IP assignment in DNSMasq, then reboot the device. It just gets the dynamic IP back. The devices have no options to do anything else.

If I use the magnifier glass next to the dynamic lease in DNSmasq it takes me to the static assignment record. But still the device IP doesn't change until the lease expires.

The workarounds I have used:

1. Stop DNSMasq, edit the DNSMasq active leases file and remove unwanted leases or change the lease time, then start DNSMasq again. I haven't seen any side effects but I don't like editing files as I'll never know when it might cause a problem.

2. After the static assignment is in place, do a factory reset on the device then configure it again. Doable but not really desirable. And doesn't always work; some devices STILL get the dynamic active lease back.

3. Set the default lease time to something short *before* I connect the new device for the first time. I also need to wait until some devices (that tend to behave badly during lease renewals) are not going to be renewing during this time. If I forget to alter the default lease time then it's back to #1 or #2 or have to wait for the lease to expire, before I can finish setting up the new device.


Are there any other options I can use, to get the reserved IP assigned when the device can't cause it to happen?


I did read in Github and elsewhere that adding a delete lease function is not planned, for reasons such as possible inconsistencies. Could the active lease time be edited in the GUI to some minimum time, like five minutes, so DNSMasq could expire it in a normal way and assign the reserved IP?

Since the 25.7 series, I have also noticed

My setup was simple as it could get.

I'm the OP, I'm still working on my issues, possibly related to both of yours, possibly just coincidence that I'm running smoothly right now, but I'll give you what I've got and let you try it out if you're willing.

I'm not saying this is best way to go, only that apparently it's working for me thus far and maybe you can get a stable setup too before moving on with more configuration.

1. If it isn't already, disable Unbound. Put your DNS server IP's in System -> Settings -> General.

2. I was having trouble with Health reports, I think something got corrupted in the upgrade. I went to Reporting -> Settings and reset/repaired everything, then rebooted. I had to do it a couple more times over a few weeks but reporting is working OK for now.

3. I've just moved from ISC to DNSmasq. I had DNSmasq in prior routers for years and liked it. This one is working for me too.
   - The first day was a little rocky as leases expired and got picked up by DNSMasq, but settled after that.   
   - Don't enable DNSMasq until everything is ready. Then, disable ISC and enable DNSMasq. Reboot and give it a day to settle out.
   - Leave the listen port at 53 (because unbound is disabled)
   - I followed this guide: https://homenetworkguy.com/how-to/migrate-from-isc-dhcp-to-dnsmasq-or-kea-dhcp-in-opnsense/  except for leaving the listen port at 53 and skipping all the unbound info. I also put the lease time to 0 on all my reserved IPs. I don't know if that's redundant but it is what I've done on all past DNSMasq routers I've had.

   NOTE: In ISC I had a small window of IPs available for dynamic IPs, and all the reserved IPs were defined outside of that range.
         In my past DNSMasq routers I always gave the full LAN range for DHCP and reserved IPs were scattered throughout - I did the same here. The above guide also mentions this. I honestly don't know if that's required, but it's what I've always done.

4. I found out I was getting dpinger problems with gateway monitoring. I think this was causing me some instability. Probably nothing to do with DNS issues exactly, but my internet kept going unstable and only pulling the power cable would fix it. I could probably just uncheck gateway monitoring (and may still try that).

But for now I changed the IP from what was already populated, to a hop in a tracert to any public IP. I chose the IP from the fourth hop as it responded quickly. It's still within my ISP. I am not sure how the one in OPNsense was populated, I don't recall putting anything there when I first set up and don't have any notes about it. Maybe I did it and just don't remember. In any case, using the fourth hop IP on the tracert is working well and I don't have any dpinger entries anymore.

Check your logs at System -> Gateways -> Log file and see if you have any dpinger warnings or errors expecially "exit on signal 15" which I think means it was killed and restarted. (?)  If you have warnings or errors, go to System -> Gateways -> Configuration and enter that fourth hop IP for monitoring. Or just try a reliable one like 1.1.1.1 or 8.8.8.8, something for your test that has a consistent fast response and solid uptime.


If you are willing to try the above and if your internet becomes stable after a day or two (and maybe a couple of reboots at intervals), then we might be able help shed some light on why the most basic near-default installs seem to have trouble with DNS.

Let us know?

Kind regards.

I have not tried to enable Unbound again since for the most part things have been working without it. It hasn't been entirely stable but I haven't had time to figure out what or why (dealing with a sudden death in the family and other issues). Hopefully soon after the first of year I will find time to reformat with ZFS and try a fresh install with defaults as before, tweaking little else. Thanks for the followup.

Thanks for your comments.

What browser are you using, if using firefox there are some changes in firefox that have to be made or firefox DNS will fight with unbound DNS.

Multiple machines, multiple browsers, email clients, other programs that access the internet, multiple OS (Windows multiple versions, Ubuntu).

You should leave unbound enabled at default except check flush cache on reboot. Nothing to do there for a basic setup.put your dns servers in system>settings>general>dns.

I was informed that if DNS is configured in system->settings... instead of Unbound, then Unbound is not doing anything even if enabled. I didn't test that; I moved my DNS from Unbound to system->settings... and disabled Unbound. Then DNS started working normally.

Just to the right of each one is a gateway drop down bubble. If it doesnt show A IPV4 gateway. Wait for a DHCP connection, then click the drop down bubble and it should be there. Have to attach a IPV4 gateway there. Its a bug I mentioned on the forum before.

None of those things went wrong for me, it was all there as it should be. Unbound DNS became flakier and flakier over varying periods of time until it stopped working completely. Clearing Unbound cache and reboot got it working again but only for short periods. Until I moved DNS and disabled Unbound, then all DNS problems stopped.

Make sure you wipe the opnsense drive before a reinstall if you know how. It has a possibility of carrying data over to the new system. Wipe the RAM.

I will be using ZFS and I'm assuming it will completely format the disk (I've never used it). I suppose I'll find out when I get there.

That went right over my head. It's OK. Thanks for trying to help.