Messages

[## Versions]

Hi there,

on 08.01.2025 my telegraf plugin stopped reporting any ping metrics other than "response_code = 2" for no apparent reason.
I did not execute any updates in that time, nor did I change the configuration in any way - it just stopped.

The Telegraf logs for each interval look like these:

Code Select Expand

                                 64 bytes from 8.8.8.8: icmp_seq=64 ttl=119 time=5.354 ms
[...]
                                 64 bytes from 8.8.8.8: icmp_seq=2 ttl=119 time=5.522 ms   
                                 64 bytes from 8.8.8.8: icmp_seq=1 ttl=119 time=6.754 ms   
                                 64 bytes from 8.8.8.8: icmp_seq=0 ttl=119 time=6.105 ms   
2025-01-16T09:35:05              E! [inputs.ping] Error in plugin: host "8.8.8.8": command timed out - PING 8.8.8.8 (8.8.8.8): 56 data bytes   
2025-01-16T09:35:05              E! [agent] Error terminating process children: no such process

The ping execution stops after sequence number 64 instead of 99 (ping count configured is 100)


Here is the progression over time from Grafana:

https://imgur.com/a/o2p2qHB


## Versions
OPNsense: 24.7.11_2
os-telegraf: 1.12.12
telegraf: 1.33.0


## Telegraf inputs.ping configuration
Ping (IPv4): enabled
Ping Count (IPv4): 100
Ping Hosts (IPv4): 8.8.8.8


## What I did so far
- OPNsense update from 24.7.11_2 to 24.7.12
- Uninstall/Reinstall of the Telegraf plugin
- Tested running the Telegraf plugin as root


Does anybody have an idea what could cause this issue?


Thank you in advance!

Regards,
Senten

Hi and thanks for sharing your experience!

Was your problem with local dns resolving, too?
Sounds like you are using external dns servers:

I have the same issue with a free duckdns.org domain (the nameservers have high latency)

If so, you likely had a different issue, as my problem only exists with locally hosted RRs in my xyz.local domain.

I tried your suggested setting though but the same error logs are still appearing with every ip alias resolving period.

Hi there,

I already posted about this issue in the german sub forum but didn't get any response there, so I am reposting in the international section.

Translated from original post:

Hello dear community,

I recently set up a logging server and through this i stumbled upon the following problem:

The pf firewall randomly does not resolve FQDN firewall aliases. Milliseconds later the same name is resolved correctly:

Code Select Expand

2024-01-18 08:25:06.560 resolving 1 hostnames (1 addresses) for ##### took 0.02 seconds
2024-01-18 08:19:08.284 resolving 1 hostnames (1 addresses) for ##### took 0.01 seconds
2024-01-18 08:18:32.324 resolving 1 hostnames (1 addresses) for ##### took 0.01 seconds
2024-01-18 08:18:05.878 resolving 1 hostnames (1 addresses) for ##### took 0.01 seconds
2024-01-18 08:12:08.150 resolving 1 hostnames (1 addresses) for ##### took 0.01 seconds
2024-01-18 08:12:07.930 resolving 1 hostnames (0 addresses) for ##### took 2.03 seconds
2024-01-18 08:12:07.910 The DNS query name does not exist: ##### [for #####]
2024-01-18 08:07:03.941 resolving 1 hostnames (1 addresses) for ##### took 0.01 seconds
2024-01-18 08:01:07.082 resolving 1 hostnames (1 addresses) for ##### took 0.02 seconds
2024-01-18 08:01:06.983 resolving 1 hostnames (0 addresses) for ##### took 2.03 seconds
2024-01-18 08:01:06.973 The DNS query name does not exist: ##### [for #####]
2024-01-18 07:55:09.124 resolving 1 hostnames (1 addresses) for ##### took 0.01 seconds
2024-01-18 07:50:04.179 resolving 1 hostnames (1 addresses) for ##### took 0.02 seconds
2024-01-18 07:44:08.971 resolving 1 hostnames (1 addresses) for ##### took 0.01 seconds
2024-01-18 07:44:08.300 resolving 1 hostnames (0 addresses) for ##### took 2.03 seconds
2024-01-18 07:44:08.284 The DNS query name does not exist: ##### [for #####]
2024-01-18 07:38:06.104 resolving 1 hostnames (1 addresses) for ##### took 0.01 seconds
2024-01-18 07:38:06.002 resolving 1 hostnames (0 addresses) for ##### took 2.04 seconds
2024-01-18 07:38:05.982 The DNS query name does not exist: ##### [for #####]
2024-01-18 07:32:06.035 resolving 1 hostnames (1 addresses) for ##### took 0.01 seconds
2024-01-18 07:26:06.578 resolving 1 hostnames (1 addresses) for ##### took 0.01 seconds

The above logs are filtered for the same Alias (even though others are affected too). The FQDN can be resolved using dig or nslookup just fine without any errors or timeouts or whatsoever.

My system is running OPNsense 23.7.12 24.1_1, the error existed already with 23.7.10 and likely even before that.

The dns server used is the local unbound service.

At System>Settings>General the following settings are *not* checked:

Code Select Expand

DNS server options
[ ] Allow DNS server list to be overridden by DHCP/PPP on WAN
[ ] Do not use the local DNS service as a nameserver for this system

Does anybody here have an idea what the cause could possibly be or what I could take a more detailed look at?

Thank you in advance!

Regards,
Senten

Hi there,

I think I have the same issue and posted in the german sub forum about it (unfortunately no anwers yet):

Translated from original post:

Hello dear community,

I recently set up a logging server and through this i stumbled upon the following problem:

The pf firewall does not resolve FQDN firewall aliases once every ~6 Minutes. Milliseconds later the same name is resolved correctly:

Code Select Expand

2024-01-18 08:25:06.560 resolving 1 hostnames (1 addresses) for ##### took 0.02 seconds
2024-01-18 08:19:08.284 resolving 1 hostnames (1 addresses) for ##### took 0.01 seconds
2024-01-18 08:18:32.324 resolving 1 hostnames (1 addresses) for ##### took 0.01 seconds
2024-01-18 08:18:05.878 resolving 1 hostnames (1 addresses) for ##### took 0.01 seconds
2024-01-18 08:12:08.150 resolving 1 hostnames (1 addresses) for ##### took 0.01 seconds
2024-01-18 08:12:07.930 resolving 1 hostnames (0 addresses) for ##### took 2.03 seconds
2024-01-18 08:12:07.910 The DNS query name does not exist: ##### [for #####]
2024-01-18 08:07:03.941 resolving 1 hostnames (1 addresses) for ##### took 0.01 seconds
2024-01-18 08:01:07.082 resolving 1 hostnames (1 addresses) for ##### took 0.02 seconds
2024-01-18 08:01:06.983 resolving 1 hostnames (0 addresses) for ##### took 2.03 seconds
2024-01-18 08:01:06.973 The DNS query name does not exist: ##### [for #####]
2024-01-18 07:55:09.124 resolving 1 hostnames (1 addresses) for ##### took 0.01 seconds
2024-01-18 07:50:04.179 resolving 1 hostnames (1 addresses) for ##### took 0.02 seconds
2024-01-18 07:44:08.971 resolving 1 hostnames (1 addresses) for ##### took 0.01 seconds
2024-01-18 07:44:08.300 resolving 1 hostnames (0 addresses) for ##### took 2.03 seconds
2024-01-18 07:44:08.284 The DNS query name does not exist: ##### [for #####]
2024-01-18 07:38:06.104 resolving 1 hostnames (1 addresses) for ##### took 0.01 seconds
2024-01-18 07:38:06.002 resolving 1 hostnames (0 addresses) for ##### took 2.04 seconds
2024-01-18 07:38:05.982 The DNS query name does not exist: ##### [for #####]
2024-01-18 07:32:06.035 resolving 1 hostnames (1 addresses) for ##### took 0.01 seconds
2024-01-18 07:26:06.578 resolving 1 hostnames (1 addresses) for ##### took 0.01 seconds

The above logs are filtered for the same Alias (even though others are affected too). The FQDN can be resolved using dig or nslookup just fine without any errors or timeouts or whatsoever.

My system is running OPNsense 23.7.12, the error existed already with 23.7.10 and likely even before that.

The dns server used is the local unbound service.

At System>Settings>General the following settings are *not* checked:

Code Select Expand

DNS server options
[ ] Allow DNS server list to be overridden by DHCP/PPP on WAN
[ ] Do not use the local DNS service as a nameserver for this system

In my case I am talking about A/AAAA records and not necessarily CNAMEs.

Is this the same issue as yours? If not so, please tell me so I can open a new thread in the English forum :-)

Regards,
Senten

Hallo zusammen,

ich möchte hier einen Vorschlag anbieten, da ich selber eine sehr ähnliche Hardware einsetze.
Meine 4 physischen Ports sind so verschaltet:

Code Select Expand


Port1 [x] -> Trunk, dient als Bridge-Port für vmbr0; Hierüber werden PVE, als auch alle anderen VMs und CTs erreicht
Port2 [ ] -> leer
Port3 [x] -> PCI-Passthrough an OPNsense-VM (WAN)
Port4 [x] -> PCI-Passthrough an OPNsense-VM (LAN | Trunk)


Port1 und Port4 sind mit dem selben Switch verbunden.

Der Zugriff von einem Client zu Proxmox verläuft dann in etwa so:

Code Select Expand

Client(VLAN100) -> Untagged Port -> Switch -> Trunk (OPNsense) -> OPNsense_eth0.100 -> OPNsense_eth0.200 -> Trunk (OPNsense) -> Switch -> Trunk (Proxmox) -> Proxmox_enp2s0 -> Proxmox_vmbr0.200 (Mgmt-IP-Adresse)
Ich hoffe ich hab mich da jetzt nicht verhaspelt :D

Durch den PCI-Passthrough sind die Ports3 und 4 exklusiv der OPNsense vorbehalten und mir persönlich gefiel die Idee der Trennung vom Hypervisor und angeblich soll es so auch performanter sein (das habe ich nicht getestet, sondern einfach darauf vertraut).

Grüße,
Senten

Hallo liebe Community,

ich habe mir kürzlich einen Logging-Server aufgesetzt und bin dadurch auf folgendes Phänomen gestoßen:

Die pf-Firewall löst sporadisch keine FW-Aliase auf Basis von FQDNs auf. Bruchteile einer Sekunde später funktioniert die Auflösung dann jedoch:

Code Select Expand

2024-01-18 08:25:06.560 resolving 1 hostnames (1 addresses) for ##### took 0.02 seconds
2024-01-18 08:19:08.284 resolving 1 hostnames (1 addresses) for ##### took 0.01 seconds
2024-01-18 08:18:32.324 resolving 1 hostnames (1 addresses) for ##### took 0.01 seconds
2024-01-18 08:18:05.878 resolving 1 hostnames (1 addresses) for ##### took 0.01 seconds
2024-01-18 08:12:08.150 resolving 1 hostnames (1 addresses) for ##### took 0.01 seconds
2024-01-18 08:12:07.930 resolving 1 hostnames (0 addresses) for ##### took 2.03 seconds
2024-01-18 08:12:07.910 The DNS query name does not exist: ##### [for #####]
2024-01-18 08:07:03.941 resolving 1 hostnames (1 addresses) for ##### took 0.01 seconds
2024-01-18 08:01:07.082 resolving 1 hostnames (1 addresses) for ##### took 0.02 seconds
2024-01-18 08:01:06.983 resolving 1 hostnames (0 addresses) for ##### took 2.03 seconds
2024-01-18 08:01:06.973 The DNS query name does not exist: ##### [for #####]
2024-01-18 07:55:09.124 resolving 1 hostnames (1 addresses) for ##### took 0.01 seconds
2024-01-18 07:50:04.179 resolving 1 hostnames (1 addresses) for ##### took 0.02 seconds
2024-01-18 07:44:08.971 resolving 1 hostnames (1 addresses) for ##### took 0.01 seconds
2024-01-18 07:44:08.300 resolving 1 hostnames (0 addresses) for ##### took 2.03 seconds
2024-01-18 07:44:08.284 The DNS query name does not exist: ##### [for #####]
2024-01-18 07:38:06.104 resolving 1 hostnames (1 addresses) for ##### took 0.01 seconds
2024-01-18 07:38:06.002 resolving 1 hostnames (0 addresses) for ##### took 2.04 seconds
2024-01-18 07:38:05.982 The DNS query name does not exist: ##### [for #####]
2024-01-18 07:32:06.035 resolving 1 hostnames (1 addresses) for ##### took 0.01 seconds
2024-01-18 07:26:06.578 resolving 1 hostnames (1 addresses) for ##### took 0.01 seconds

Die obigen Log-Zeilen beziehen sich alle auf den selben FW-Alias und der angefragte FQDN ist korrekt.
Wenn ich betroffene Namen per dig manuell auflöse, kommt es niemals zu einem Timeout oder sonstigen Fehler.

Mein System läuft auf OPNsense 23.7.12, der Fehler bestand aber definitiv bereits mit 23.7.10 und vermutlich auch davor schon.

Zur DNS-Auflösung wird der lokale Unbound-Dienst verwendet.

Unter System>Settings>General sind die folgenden Optionen *nicht* aktiv:

Code Select Expand

DNS server options
[ ] Allow DNS server list to be overridden by DHCP/PPP on WAN
[ ] Do not use the local DNS service as a nameserver for this system

Hat jemand eine Idee woran das liegen kann oder was ich mir genauer ansehen könnte?

Vielen Dank!

Grüße,
Senten

Edit: Rechtschreibkorrektur

It has to do something with AdGuard.

I retried AdGuard on a fresh install on port 53 and checked the box.

DHCP DNS for IPV6 stopped working.

Reinstalled fresh, no AdGuard. DNC DNS for IPV6 worked.

Seems easy to reproduce and test but I really have no use for AdGuard as I just use the same 2 blocklists for Unbound.

That's interesting, because I think I found the issue on my end:

Turned out my client was not using the DHCP lease reserved for it because its' MAC-address changed due to the local Hyper-V service kidnapping the adapter ... .

For some reason my client did not pick up a different DHCP lease with its' now virtual MAC-address but was served only through SLAAC instead.

The RD daemon was not restarted yet though and this might have been the reason, why it still propagated the global system default dns servers.

After deleting the Hyper-V-virtual-switch and regaining the original MAC-address, my client accepted the reserved DHCP lease and was told to use the correct dns servers for IPv4 and v6.

After restarting the RD daemon android clients received the correct dns configuration, too.

Regards,
Senten

I noticed with AdGuardHome 1.9 as primary DNS only the IPv4 address is advertised correctly but IPv6 still falls back to the system default servers:

   DNS-Server  . . . . . . . . . . . : 2620:fe::fe (quad9)
                                       2620:fe::9 (quad9)
                                       10.10.0.1 (AdGuardHome)

Is that a config error on my side or was it maybe overlooked in the 1.9 release?

Did you enable the new checkbox in the Services > Adguard Home page?

Good call! Of course I did'nt   ::)

Problem solved - thanks a lot  ;D

A fix is mentioned in the current change log but the behaviour hasn't changed for my case.

Plugin Changelog
================

1.9

* Fix DNS settings introduced with 23.1.6
* Update to latest version

There already is a github issue for this: https://github.com/mimugmail/opn-repo/issues/153

Hi and thanks for the link.

If I understand correctly the issue is with the AdGuard plugin from the mimugmail repository not being ready for opnsense 23.1.6 and the problem only exists with AdGuard being configured with Port 53.

Setting the advertised dns server ip addresses statically is one workaround.

Usind a different port for AdGuard and forwarding from Unbound/Bind to AdGuard being another one.

A third workaround seems to be using port 53 on both AdGuard and Unbound/Bind and making AdGuard listen to a dedicated virtual IP address with NAT port forward.

Let's hope the AdGuard plugin will get an update addressing this soon :-)

Hi there,

I have updated my opnsense from 23.1.5 to 23.1.6(-amd64) yesterday and after that the DHCP service advertised the globally configured system dns-servers (public ones) instead of the interface ip addresses, as it used to be.

I am running AdGuardHome as the main DNS service and unbound as forwarder with a few local overrides. That means  after the update clients can resolve public names but not the ones i only use locally.

As a result I now have to manually set the interface ip addresses as the dns servers in the DHCP configuration, which i used to leave blank. In order to be able to do that for IPv6 I now have to additionally configure virtual fd00 IP aliases, which I do not need for anything else an actually would like to deconfigure again as soon as possible.

I tried rolling back a snapshot of 23.1.5 and this version does not have the problem.

Is this a bug or expected behavior? I read about some changes regarding bind hooks in the changelog but as I am not running bind I suppose that does not affect me?

Regards and thanks in advance,
Senten