Topics

1

20.7 Legacy Series / unbound - DoT Servers with ipv6 address

« on: December 29, 2020, 09:02:17 pm »

High there,

I have a question around unbound and ipv6 based DNS servers:

I am running my sense behind a fritzbox with Telekom as ISP. The fritzbox acts as a gateway and is talking in ipv6 via Link local addresses (fe80: XXX ....) with the WAN interface of the Sense. I have configured DoT with unbound and from the sense itself, I can query directly the ipv6 addresses of the configured DoT servers. Also all ipv4 queries work fine.

Not so from LAN: when running unbound on debug level 4, I get the following error messages:

Code: [Select]

unbound[99672]: [99672:1] debug: iter_handle processing q with state QUERY TARGETS STATE
unbound[99672]: [99672:1] debug: servselect ip6 2606:4700:4700::1111 port 853 (len 28)
unbound[99672]: [99672:1] debug: servselect ip6 2606:4700:4700::1001 port 853 (len 28)
unbound[99672]: [99672:1] debug: servselect ip6 2620:fe::11 port 853 (len 28)
unbound[99672]: [99672:1] debug: servselect ip4 9.9.9.11 port 853 (len 16)
unbound[99672]: [99672:1] debug: servselect ip4 1.1.1.1 port 853 (len 16)
unbound[99672]: [99672:1] debug:    rtt=2494
unbound[99672]: [99672:1] debug:    rtt=2915
unbound[99672]: [99672:1] info: sending query: apple-dns.net. DS IN
unbound[99672]: [99672:1] debug: dnssec status: not expected
--> unbound[99672]: [99672:1] error: outgoing tcp: bind: Can't assign requested address
unbound[99672]: [99672:1] debug:    ip4 1.0.0.1 port 853 (len 16)
unbound[99672]: [99672:1] debug: attempt to get extra 3 targets
unbound[99672]: [99672:1] debug:    rtt=275
unbound[99672]: [99672:1] debug:    rtt=376
unbound[99672]: [99672:1] debug:    rtt=376
unbound[99672]: [99672:1] debug:    rtt=2494
unbound[99672]: [99672:1] debug: servselect ip4 1.0.0.1 port 853 (len 16)
unbound[99672]: [99672:1] debug: selrtt 275
unbound[99672]: [99672:1] debug: sending to target: <.> 2606:4700:4700::1001#853
--> unbound[99672]: [99672:1] error: outgoing tcp: bind: Can't assign requested address
unbound[99672]: [99672:1] debug:    ip6 2606:4700:4700::1111 port 853 (len 28)
unbound[99672]: [99672:1] debug:    ip4 1.1.1.1 port 853 (len 16)
unbound[99672]: [99672:1] debug: servselect ip6 2606:4700:4700::1111 port 853 (len 28)
unbound[99672]: [99672:1] debug: servselect ip6 2606:4700:4700::1001 port 853 (len 28)

When I delete all ipv6 addresses from the DoT list, there is no error message. Obviously, unbound can not contact the ipv6 DNS server from LAN via the gateway (see marked line) - but why ? 

I could imagine that this might be a config issue. Does anyone has an advice for me where to look into?

Thank you very much for your advice

BR br

2

20.7 Legacy Series / DNS Servers with ipv6 addresses not usable with LL ipv6 gateway addresses

« on: October 24, 2020, 01:28:05 pm »

Hi there,

after successfully upgrade to 20.7.4 I digged again into an issue which I notified in 20.7.3 already. It seems to be that neither for dnsmask nor for unbound, DNS Servers with ipv6 addresses (as eg configured in System->Einstellungen->Allgemein) can be used as the static host routes for those DNS Servers are not configured properly when the resolve.conf is rebuild.

Reason seems to be that IF the ipv6 gateway address is link local, the route command is misconfigured in /usr/local/etc/inc/system.inc: function system_resolvconf_generate($verbose = false).

There is an error message generated in system.log

Code: [Select]

Oct 24 12:15:43 OPNsense.zuhause.xx opnsense[9135]: /usr/local/etc/rc.newwanipv6: The command '/sbin/route add -host -'inet6' '2001:470:20::2' 'fe80::3ea6:2fff:fe15:9055%'' returned exit code '71', the output was
 'route: fe80::3ea6:2fff:fe15:9055%: Name does not resolve'Note the '%' sign in the 'fe80 ....' gateway address which is either obsolete or (perhaps even better) needs a Zone ID like the WAN interface name which would make the address look like 'fe80::3ea6:2fff:fe15:9055%igb1' as an example.

Such an error message is contained for all configured DNS Servers with ipv6 addresses

Adding a proper zone ID or removing the '%' make these error messages disappear and the ipv6 DNS servers are started to be used (however there may be configs where missing zone IDs are not appropriate)

Not sure whether this is appropriate to be fixed in system.inc here:

Code: [Select]

Line 202 ff
            (...)
            $gwname = $syscfg[$dnsgw];
            if (($gwname != '') && ($gwname != 'none')) {
                $gatewayip = $gateways->getAddress($gwname);
                if (is_ipaddrv4($gatewayip)) {
                    /* dns server array starts at 0 */
                    $dnscountermo = $dnscounter - 1;
                    system_host_route($syscfg['dnsserver'][$dnscountermo], $gatewayip);
                }
                if (is_ipaddrv6($gatewayip)) {
                    /* dns server array starts at 0 */
                                       <--- check/add Zone ID if $gatewayip is LL, similar as eg in system_default_route()
                    $dnscountermo = $dnscounter - 1;
                    system_host_route($syscfg['dnsserver'][$dnscountermo], $gatewayip);
                }
Please let me know whether it is appropriate to open a bug for this on GitHub

br br

3

20.7 Legacy Series / DNS over TLS with ipv6 forward-addresses - can't get it working

« on: October 17, 2020, 11:08:15 am »

Good morning,

I am on 20.7.3. and I am trying to get DNS over TLS working with unbound. Everything works fine as long as I use IPv4 forwarder addresses in the Services->Unbound TLS->Misc which I put eg in the form 9.9.9.9@853.

When I am adding an ipv6 address like eg 2a05:fc84::42@853 and I restart unbound, the ipv4 forward-addresses are still used/working properly, but my /var/log/resolver/resolver.log gets flooded with

Code: [Select]

Oct 17 10:54:33 OPNsense.zuhause.xx unbound[37717]: [37717:2] error: outgoing tcp: bind: Can't assign requested addressNo request to the ipv6 server is then sent indeed. Removing the address and restarting unbound make the error message disappear again.

My resulting /var/unbound/etc/dot.conf looks like

Code: [Select]

server:
  tls-cert-bundle: /etc/ssl/cert.pem
forward-zone:
  name: "."
  forward-tls-upstream: yes
  forward-addr: 9.9.9.9@853
  forward-addr: 149.112.112.112@853
  forward-addr: 1.1.1.1@853
  forward-addr: 1.0.0.1@853
  forward-addr: 2a05:fc84::42@853
which looks correct to me

There has been an (pretty much) earlier thread on that error message and DoT
https://forum.opnsense.org/index.php?topic=12301.0
after which the DoT (GUI) functionality has been substantially expanded/refactored, however I use recommended forward addresses for my region.

ipv6 Gateway and Wan addresses are both LL. When I run unbound in debug mode, all queries which try to use

Code: [Select]

outgoing-interface: fe80::XXX:YYY:ZZZ:a21dcreate the error message above.

Has someone an idea what could be wrong here or how to debug this further?

Thanks a lot

Br br

4

20.7 Legacy Series / unbound - ipv6 static route error - zone ID missing ?!

« on: October 14, 2020, 07:46:48 pm »

Hi all,

I am just trying to get up DoT with unbound and when I restart unbound after a config change I get the following error message

Code: [Select]

Oct 14 18:44:10 OPNsense.zuhause.xx opnsense[99771]: /services_unbound.php: The command '/sbin/route add -host -'inet6' '2001:470:20::2' 'fe80::3ea6:2fff:fe15:9055%''
 returned exit code '71', the output was 'route: fe80::3ea6:2fff:fe15:9055%: Name does not resolve'
2001:470 ....is one of my ipv6 DNS Servers configured in system->general, while the fe80 address is my ipv6 gateway. I have these lines in the system log file for each ipv6 dns server.

It seems that there is the Zone ID of my WAN interface missing/incomplete.

Any idea how to correct ?

Looking forward to your reply

Br br

5

20.7 Legacy Series / syslog-ng: logging reduced/incomplete

« on: September 28, 2020, 02:24:12 pm »

Hi there,

I updated yesterday finally to 20.7.3 from 20.1.9_1, which ran very smooth on my X11-SBA LN4F Supermicro System. All services came up again, there is one thing left which is syslog-ng.

After the restart I had both syslog and syslog-ng running which I solved by deactivating circular logs. Since then, syslog-ng runs stable. However, not all relevant running services are being logged. According to /usr/local/etc/syslog-ng.conf.d/syslog-ng-local.conf, I should see dedicated directories in /var/log/ for

• configd +
• dhcpd +
• dnsmasq
• filter +
• gateways *
• ipsec
• lighttpd +
• ntpd *
• openvpn
• pkg *
• portalauth +
• ppp
• haproxy/relayd
• routing +
• squid
• suricata
• system +
• syslog-ng +

and some more, containing timestamped log files for the individual services. I assume, that indeed loggers are created only if the corresponding service is running.

Service Logs in table above having a '+' are created and contain logs, lines having a '*' have a running service but no logs are created, no tag in the table means that the corresponding service is not active. Saving the config and restart of the service did not help.

Any idea how to get the missing logs for the running services up?

Br br

6

19.1 Legacy Series / [SOLVED] Upgrade to 19.1.1 - no ipv6 gateway

« on: February 17, 2019, 02:02:02 pm »

Hi,

after upgrading to 19.1.1 from 18.7, the ipv6 gateway is shown as offline and cannot be started from GUI anymore. The issue is that there is no rtsold process anymore pickup the prefix from WAN and  also dhcp6d can not be started.

The logs do not show any hint except that they state that there is no ipv6 default route possible to be set;

Code: [Select]

Feb 17 13:53:54 OPNsense opnsense: /interfaces.php: The command '/bin/pkill -'HUP' 'php-cgi'' returned exit code '1', the output was ''
Feb 17 13:53:54 OPNsense opnsense: /interfaces.php: ROUTING: entering configure using defaults
Feb 17 13:53:54 OPNsense opnsense: /interfaces.php: ROUTING: IPv4 default gateway set to wan
Feb 17 13:53:54 OPNsense opnsense: /interfaces.php: ROUTING: IPv6 default gateway set to wan
Feb 17 13:53:54 OPNsense opnsense: /interfaces.php: ROUTING: setting IPv4 default route to 192.168.2.1
Feb 17 13:53:54 OPNsense opnsense: /interfaces.php: ROUTING: keeping current default gateway '192.168.2.1'
Feb 17 13:53:54 OPNsense opnsense: /interfaces.php: ROUTING: skipping IPv6 default route
Feb 17 13:54:51 OPNsense opnsense: /interfaces.php: ROUTING: entering configure using 'wan'
Feb 17 13:54:51 OPNsense opnsense: /interfaces.php: ROUTING: IPv4 default gateway set to wan
Feb 17 13:54:51 OPNsense opnsense: /interfaces.php: ROUTING: IPv6 default gateway set to wan
Feb 17 13:54:51 OPNsense opnsense: /interfaces.php: ROUTING: setting IPv4 default route to 192.168.2.1
Feb 17 13:54:51 OPNsense opnsense: /interfaces.php: ROUTING: removing /tmp/igb1_defaultgw
Feb 17 13:54:51 OPNsense opnsense: /interfaces.php: ROUTING: creating /tmp/igb1_defaultgw using '192.168.2.1'
Feb 17 13:54:51 OPNsense opnsense: /interfaces.php: ROUTING: skipping IPv6 default route
Feb 17 13:54:57 OPNsense opnsense: /interfaces.php: Warning! services_radvd_configure(auto) found no suitable IPv6 address on igb2
Feb 17 13:54:57 OPNsense opnsense: /interfaces.php: Warning! services_radvd_configure(auto) found no suitable IPv6 address on igb0
Feb 17 13:54:57 OPNsense opnsense: /interfaces.php: Warning! services_radvd_configure(auto) found no suitable IPv6 address on igb3

dpinger can not be started as well (clear if there is no ipv6 gateway ....)

Any idea where to look after?

Br br

7

18.7 Legacy Series / Upgrade to 18.7.4: telegraf plugin broken?

« on: September 28, 2018, 10:19:08 pm »

Hi there,

after I upgraded to 18.7.4. I noticed that the telegraph plugin seems to be broken, mainly due to the input.systems module; I have no suddenly two log files, one in /var/log/telegraf/telegraf.log and one in /var/log/telegraf.log. Although the config says

Code: [Select]

[global_tags]

[agent]
  interval = "10s"
  round_interval = false
  metric_batch_size = 1000
  metric_buffer_limit = 10000
  collection_jitter = "0s"
  flush_jitter = "0s"
  precision = ""
  debug = false
  quiet = true
  logfile = "/var/log/telegraf.log"
  hostname = "opnsense"
  omit_hostname = false

[[outputs.influxdb]]
  urls = ["http://192.168.1.205:8086"]
  database = "telegraf"
  retention_policy = ""
  write_consistency = "any"
  timeout = "5s"
  username = "influx"
  password = "XXXXXXXXXX"




[[inputs.cpu]]
  percpu = true
  totalcpu = true
  collect_cpu_time = false

[[inputs.disk]]
  mount_points = ["/"]

[[inputs.diskio]]

[[inputs.mem]]

[[inputs.processes]]


[[inputs.system]]

[[inputs.net]]
that /var/log/telegraf.log shall be used, it uses the other one and writes tons of messages like

Code: [Select]

2018-09-28T19:20:23Z E! Error in plugin [inputs.system]: open /var/run/utmp: no such file or directory
2018-09-28T19:20:33Z E! Error in plugin [inputs.system]: open /var/run/utmp: no such file or directory
2018-09-28T19:20:43Z E! Error in plugin [inputs.system]: open /var/run/utmp: no such file or directory
2018-09-28T19:20:53Z E! Error in plugin [inputs.system]: open /var/run/utmp: no such file or directory
2018-09-28T19:21:03Z E! Error in plugin [inputs.system]: open /var/run/utmp: no such file or directory
2018-09-28T19:21:13Z E! Error in plugin [inputs.system]: open /var/run/utmp: no such file or directory
2018-09-28T19:21:23Z E! Error in plugin [inputs.system]: open /var/run/utmp: no such file or directory
2018-09-28T19:21:33Z E! Error in plugin [inputs.system]: open /var/run/utmp: no such file or directory
2018-09-28T19:21:43Z E! Error in plugin [inputs.system]: open /var/run/utmp: no such file or directory
2018-09-28T19:21:53Z E! Error in plugin [inputs.system]: open /var/run/utmp: no such file or directory
2018-09-28T19:22:03Z E! Error in plugin [inputs.system]: open /var/run/utmp: no such file or directory
E! Unable to append to /var/log/telegraf.log (open /var/log/telegraf.log: permission denied), using stderr
/var/log/telegraf.log belongs now root:root but should root:telegraf (?),

The non-nice side effect is that opnsense throughput in downlink drops to <5% of the normal performance.

Br br

8

18.1 Legacy Series / 18.1.10: dpinger activation -how to replace apinger

« on: June 21, 2018, 07:46:36 pm »

Hi there,

with pleasure i noticed that now a package for dpinger is provided with 18.1.10. Do I assume right that for now no GUI support for   dpinger is provided?

If so is there a safe recommendation how to replace apinger with dpinger via console?

Looking forward to your reply

Br br

 

9

18.1 Legacy Series / [SOLVED] Error when installing 18.1.9

« on: May 31, 2018, 09:06:20 pm »

Hi there

Get an error when installing 18.1.9. Installation screen hangs with extracting opnsense-18.1.9 and the following error message appears:

Code: [Select]

[31-May-2018 20:58:01 Europe/Berlin] PHP Fatal error:  Uncaught Error: Class 'OPNsense\Core\Routing' not found in /usr/local/opnsense/mvc/app/config/services_api.php:87
Stack trace:
#0 [internal function]: Closure->{closure}()
#1 [internal function]: Phalcon\Di\Service->resolve(NULL, Object(Phalcon\Di\FactoryDefault))
#2 [internal function]: Phalcon\Di->get('router', NULL)
#3 [internal function]: Phalcon\Di->getShared('router')
#4 /usr/local/opnsense/www/api.php(26): Phalcon\Mvc\Application->handle()
#5 {main}
  thrown in /usr/local/opnsense/mvc/app/config/services_api.php on line 87
Any idea how to fix that?

Br br

10

17.7 Legacy Series / igmpproxy and Telekom Entertain behind Fritzbox - now working

« on: January 02, 2018, 05:58:24 pm »

Hi all,

the same procedure as every year - but this time with progress:  igmpproxy in 17.7 now working with Telekom Entertain and Opnsense behind a Fritzbox as Router. Several topics dealt with that over the last 18 months eg https://forum.opnsense.org/index.php?topic=1968.0,https://forum.opnsense.org/index.php?topic=5295.0.

Over the last year there has been some updates of igmpproxy coming from pfsense space and fed back to freebsd ports, eg https://redmine.pfsense.org/issues/6099. Also, the problems with the correct aging of mcast routes in the table seems to be fixed now. Although not knowing whether all of them are fully reflected in the igmpproxy plugin of the current Opnsense release 17.7.11, I could make it work at least for Telekom Entertain 1.0 (NOT yet proven for the new Telekom Entertain TV 2.0) at least for the following configuration:

                                                                                 ----
                                                                            +-+ S +------> DMZ   <-----> Client
                                                                            |   | W |
Telekom ISP <--> Fritzbox 3490 <--> Opnsense <--+-+ I  +------> LAN    <-----> Client
                                                                            |   | T  |
                                                                            +-+ C +------> WLAN <-----> Client
                                                                                | H  |
                                                                                 ----
The switch supports IGMPv3 snooping and provides separated networks for DMZ, LAN, WLAN via untagged VLANs

After installation of the igmpproxy plugin, the following upstream networks should be configured:

• 193.158.0.0/15
• 87.140.0.0/15
• 224.0.0.0/4

The downstream networks should contain the networks of the LAN side interfaces accordingly.

The resulting /usr/local/etc/igmpproxy.conf should look like eg

Code: [Select]

##------------------------------------------------------
## Enable Quickleave mode (Sends Leave instantly)
##------------------------------------------------------
quickleave
phyint igb1 upstream ratelimit 0 threshold 1
altnet 193.158.0.0/15
altnet 224.0.0.0/4
altnet 87.140.0.0/15

phyint igb0 downstream ratelimit 0 threshold 1
altnet 192.168.X.0/24

phyint igb2 disabled
phyint igb3 disabled

Indeed you can also configure more downstream interfaces (in my case disabled here) important is to have ONE single upstream interface with the shown networks .... At the moment, I don't have yet a BNG network connection (migration announced for Q1), might be that then the upstream networks needs to be adapted.

Then, some firewall rules need to be configured:
On WAN interface:

• IPv4 IGMP from all sources, all ports to dest 224.0.0.0/4, all ports, activate extension
• IPv4 UDP from all sources, all ports to dest 224.0.0.0/4, all ports, activate extension

On LAN

• activate also extensions on all general rules

Then, very important, under Interfaces->WAN, the box 'block private networks' may NOT be ticked. Otherwise, Opnsense igmpproxy does not see the IGMP Queries from the Fritzbox anymore which prevents in time answers with member reports from the Opnsense and the Fritzbox stops the UDP stream after 2-3 mins.

In my config, TV can be seen stable on all devices in my LAN and WLAN with the vlc player. Thanks to IGMPV3 snooping capable switch, the additional traffic load on the LAN is neglectible ....

I will go for testing of direct connected Opnsense to Draytec Modem (leave out fritzbox) in the next step; as well I am currently working on a full igmpv3 implementation on the downstream side (this seems to be a prerequisite to make Entertain TV 2.0 work)...

Br br

11

17.7 Legacy Series / Update 17.7.8: apinger and ipv6 gateway monitoring not working

« on: November 22, 2017, 09:07:38 pm »

Hi there,

after upgrading to 17.7.8, ipv6 gateway monitoring is not working after reboot anymore. apinger.conf does not contain any target ... entry for the ipv6 gateway, only vor ipv4.

Simply restarting apinger does not help in my case.

Fix has been by going into system->gateways->all, then go into the config page for the ipv6 gateway and press Save. Then restart apinger and the target .... entry is in apinger.conf again. however, it is wrong one address (Link local WAN interface not Link Local WAN gateway).

With the next automatic restart, it went back to the correct values again

I can reproduce this when rebooting

Br br

12

17.7 Legacy Series / [SOLVED] IPv6 and letsencrypt

« on: October 26, 2017, 10:37:39 pm »

Hi there,

I am running a configuration like

FritzBox<-->opnsense (dmz interface) <--> web server with dyndns.

The web server acts as a public subdomain (sub.example.com)  and shall now get an ssl certificate via letsencrypt. As I have a dual stack running, Dyndns takes the ipv6 address of the Fritzbox as the ipv6 subdomain address. So far so good.

Due to the fact that Dyndns now offers ipv4 AND ipv6 a  DNS AAAA record iss created for the domain and therefore lets encrypts certbot is using ipv6 for certificate installation and renewal; obviously fallback to ipv4 is still not working in case that there is no answer from the server from ipv6. Currently certbot is failing as it does not reach the servers directory via ipv6

As with public ipv6 addresses NAT is no longer the valid method, how do I tell opnsense, that it should 'forward' the Fritzbox ipv6 address to the (public ?) ipv6 address of the webserver?

Looking forward to your reply

Br br

[EDIT] For those who are interested: The workaround is to configure the dyndns client on the FritzBox to update ipv4 only; this eliminates the AAAA record in DNS and letsencrypt is using Ipv4. To do so (here for dyn.com) Goto the Fritzbox in Internet->Freigaben->Dyndns and select user defined;  then put the following URL in the field:
https://members.dyndns.org/nic/update?hostname<DOMAIN>&myip<ipaddr>&wildcard=NOCHG&mx=NOCHG&backmx=NOCHG
Click apply and then wait for 5 min; the AAAA record has been disappeared; certbot renew then runs fine ....

13

17.7 Legacy Series / Upgrade to 17.7.4 - unbound 1.6.6 not starting automatically

« on: September 27, 2017, 11:16:22 pm »

Hi there,

17.7.4 updates also unbound to new version 1.6.6. However, unbound is not restarted after the update so that still 1.6.5 is running - is this by intention?

Br br

14

17.7 Legacy Series / [SOLVED] Adding IPv6 static route for rc.newwanipv6 fail

« on: September 24, 2017, 04:41:42 pm »

Hello,

after having fixed so fast (thanks again Franco !!) the matter around apinger (see https://forum.opnsense.org/index.php?topic=6028.0), there is another new error message in my system.log, which seems to have on a first look a similar root cause:

Code: [Select]

OPNsense opnsense: /usr/local/etc/rc.newwanipv6: Removing static route for monitor fe80::3631:c4ff:XXXX:XXXX%igb1 via fe80::3631:c4ff:XXXX:XXXX
OPNsense opnsense: /usr/local/etc/rc.newwanipv6: Adding static route for monitor fe80::3631:c4ff:XXXX:XXXX%igb1 via fe80::3631:c4ff:XXXX:XXXX
OPNsense opnsense: /usr/local/etc/rc.newwanipv6: The command '/sbin/route add -host -'inet6' 'fe80::3631:c4ff:XXXX:XXXX%igb1' 'fe80::3631:c4ff:XXXX:XXXX'' returned exit code '1', the output was 'route: writing to routing socket: Network is unreachable add host fe80::3631:c4ff:XXXX:XXXX%igb1: gateway fe80::3631:c4ff:XXXX:XXXX fib 0: Network is unreachable'

Could it be that the link local address of the default ipv6 gateway is not assigned to my WAN interface too for the adding the static route which would require some adoption of the rc.newwanipv6?

Looking forward to your reply

Br br

15

17.7 Legacy Series / [SOLVED] apinger and ipv6 gateway: cannot bind socket on address

« on: September 24, 2017, 12:44:51 am »

Hello together

after having updated to 17.7.3 from 17.1.11, I get the following error messages in the gateways.log file for the ipv6 gateway monitoring:

Code: [Select]

Could not bind socket on address(fe80::217:3fff:XXXX:XXXX) for monitoring address fe80::3631:c4ff:XXXX:XXXX(WAN_DHCP6) with error Can't assign requested address
OPNsense apinger: bind(): Can't assign requested address
Considering the /var/etc/apinger.conf, apinger sets the srcip to be the interface link-local address but it does not set the scope on the source IP or target, so apinger cannot reach the gateway.

Code: [Select]

target "fe80::3631:c4ff:XXXX:XXXX" {
  description "WAN_DHCP6"
  srcip "fe80::217:3fff:XXXX:XXXX"
        alarms override "loss","delay","down";
  rrd file "/var/db/rrd/WAN_DHCP6-quality.rrd"
}
The correct config should look (if e.g. igb1 is your WAN interface)

Code: [Select]

target "fe80::3631:c4ff:XXXX:XXXX%igb1" {
  description "WAN_DHCP6"
  srcip "fe80::217:3fff:XXXX:XXXX%igb1"
        alarms override "loss","delay","down";
  rrd file "/var/db/rrd/WAN_DHCP6-quality.rrd"
}
Have tried this out manually, with this config setting, the error message disappears.

As apinger restarts every 30 min. with a freshly written apinger.conf this needs to be included in the script generating the apinger.conf.

See also here: https://redmine.pfsense.org/issues/3969

Br br