Messages

This might not be your problem, but I've found that some providers, particularly wireless providers, sometimes drop the abnormally small ping packets sent by dpinger. For all of my gateways I set "Data Length" to 56 (you'll need to switch on "Advanced Mode" to see this option).

Just came in here again to say changing the data length to 56 has solved the issue for me (as far as dpinger giving false positives). I have been externally monitoring my own IP as well as the IP I am using for the monitor. The few failures I get now are due to monitor IP unreachable but my own connection was working.

I still need to think on monitoring as a whole in my situation. It is useful to me to know when my connection was disrupted, but only if actually true. If dpinger could check several IPs in series, and only if all fail assume the gateway unusable, it would mitigate the false positives from a single monitor IP being unreachable.

Does anyone know if there is a way to do multiple ping target IPs for the gateway monitor? Total of two or even three? If the first ping is unsuccessful, move to the second, if that's unsuccessful then try the third, and only assume the gateway is unavailable if all targets cannot be reached?

i found that using dns ip was a bad idea.

Same here, DNS IPs were fine for some testing but long term were not reliable.

For all of my gateways I set "Data Length" to 56

I believe this helped. I ran with this for the past two days. I still have a handful of dpinger entries like the ones I posted above, a significant reduction from before. I don't know for sure but the handful might be actual failures to contact my monitor IP. I still believe my own connection has been up. So now I question if using a monitor IP (in my particular situation) may give me too many false positives. I really just want to know if my own connection has been disrupted.

I have cable (Spectrum), nonetheless it's worth a try. Thank you! 😊

*** SOLVED *** see post #8   https://forum.opnsense.org/index.php?msg=260595


Currently on 26.1.1 but this started on 25.7.

OPNsense ran without issue for nearly two years, then after the upgrade to 25.7 we started having connection dropouts.

During a period of connection instability, the below is repeated several times in the gateway monitoring logs:

Warning dpinger exiting on signal 15
Notice  dpinger MONITOR: WAN_GW (Addr: xxx.xxx.xxx.xxx Alarm: down -> none RTT: 20.0 ms RTTd: 1.2 ms Loss: 0.0 %)
Warning dpinger send_interval 1000ms loss_interval 4000ms time_period 60000ms report_interval 0ms data_len 1 alert_interval 1000ms latency_alarm 0ms loss_alarm 0% alarm_hold 10000ms dest_addr xxx.xxx.xxx.xxx bind_addr xxx.xxx.xxx.xxx identifier "WAN_GW "

I have tried so many IPs, from geographically close server IPs to Cloudflare and Google DNS IPs. None have worked, though some have caused more dpinger exits than others.

Several days ago I ran these tests:

1. Configured a nearby IP known to have near 100% uptime and fast response, in gateway monitoring. With my phone on cellular only (disabled wifi radio, disabled bluetooth), I ran continuous pings on that server for several hours.

2. Changed my phone to ping my own public IP for several hours.


No pings failed, but our internet connection still dropped periodically, and the dpinger entries were in the logs.


I disabled gateway monitoring after the above tests and we haven't had any more connection drops AFAIK.

I am just a home user and my OPNsense has very few minor tweaks over the default install. And while I don't strictly need dpinger - I have no backup connection - I like having a record of internet disruption especially when I've been away.

Is there anything else I can do/look at, to troubleshoot and (hopefully) get dpinger working well again?

Thank you for any help and info.

Kind regards.

I'm up on 26.1.1 now and my internet still goes through periods of instability. It still appears to be dpinger. As best I can tell, dpinger still isn't working right.

For a test, I used my cell phone solely on cellular service (wifi radio turned off) to run ping tests across two days. One day I ran all day against the new IP I selected from my tracert (the one mentioned above, that appeared to be solid and I have dpinger monitoring), and the next day I ran ping test against my own public IP.

My cell phone never failed a ping test to either IP. But dpinger continued to fail the monitoring IP and restarted (?) my gateway assignment.

I don't have any fallback internet method, so if my internet goes down there's nothing I can do about it. It would be nice to monitor and have a notification, but it's not necessary.

I disabled gateway monitoring a few days ago and so far my internet has been up and stable...

No worries! Thank you for confirming the behavior. I'll go see about that bug report, thanks!

I've used multiple machines and multiple browsers. Auto refresh is on.

Firewall just updated to 26.1.1 and I still have the same problem.

Did you try the specific example I gave? It looks like that might be the only one that doesn't work. I tried a query src_port contains and that one worked.

I tried the above specific criteria (address, is, <value>) with multiple LAN and public IPs and none of them worked for me.

Minor bug?

Firewall -> Logs - > Live View -> Templates. I have a few templates saved from prior versions (25.7 and prior) and these work fine.

After upgrading to 26.1, I entered criteria for a template and got my expected result list. I saved it as a new template.

The saved template does not bring up any result. If I reenter criteria and apply it to the log, I get a result.

Sample criteria:

Change "action" in dropdown to "address"
Change "contains" in dropdown to "is"
Enter some address in search box that has log entries - I entered 192.168.1.9

Applying the above criteria brings up several records. I save it as a template, leave the firewall log and display some other page like the Dashboard. Then I come back to the firewall log and choose the new template. Nothing is displayed.

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.