Topics

G'day,

I just noticed an exec rights issue with the 'locate' command in 24.7.1.

Executing as root eg 'locate newwanrc', it shows

Code Select Expand


locate: the locate database '/var/db/locate.database' is smaller than 256 bytes large.

To create a new database, please run the following command as root:

  /etc/periodic/weekly/310.locate


Executing then as root

  /etc/periodic/weekly/310.locate

It only outputs

Code Select Expand


Rebuilding locate database:
Must be root.

No database is created... Also the weekly update of this database is obviously not working

Before throwing something in Git: freebsd 14.1 issue or opnsense?

br br

G'day,

Updated just to 24.7.1 which ran smooth as usual. Time to say a big thank you to all who made this happen - Great job again!!!

A (small) heads up I would like to bring to your attention which is the dyndns service resp. GUI behavior once the system reboots after update.

I am running ddclient with native backend and my dyndns update runs in two steps, one for ipv4 and one for ipv6. In between, my provider (dedyn.io) demands for a ~5 min pause and it is throttling the update requests to this interval. Already after the 24.7 (and now also 24.7.1) upgrade reboot, I am running then in a kind of (race) condition showing a very inconsistent picture about the state of the dyndns service. Reproducible, after the update reboot

• the Dashboard widget shows dyndns as 'not running', ps says it runs. Dashboard value is not changing without manual interaction
• the dyndns services page shows the correct new ipv6 address and the old ipv4 address
• the interface overview widget shows for WAN the correct new ipv4 address and ipv6 address

So, the state of internet connection reads somewhat confusing after the update ....

When manually restarting dyndns service on the dashboard service widget, nothing changes
When manually stopping dyndns and starting on the configuration page, the widget on the dashboard gets then the correct new ipv4 and ipv6 addresses; on the service configuration page, still the old ipv4 address is shown.
When manually restarting dyndns for a second time, everything is OK again.

So it takes in my case up to 10 min and two manual interactions until GUI values for WAN addresses are shown consistent to the reality.

I am aware that a fix of this is somewhat shaky as the service restart behavior is different from system to system
but perhaps over time, some optimization could be considered for this.

Br br

Hi,

As a preparation for 23.7 and migrating from legacy dyndns to ddclient, I experimented today a bit around with both ddclient backends (ddclient and the new opnsense) and dyndns2 protocol. I am with desec and I brought it up and running with the ddclient backend and the config as described here

https://forum.opnsense.org/index.php?topic=26446.msg134975#msg134975

Basically it works, however every second update cycle, an update is said to be performed successfully which does not take place according to the desec DNS logs. ddclient logs look like this:

Code Select Expand


<29>1 2023-06-08T00:53:49+02:00 OPNsense.zuhause.xx ddclient[61106] 34054 - [meta sequenceId="3"] WARNING:  Wait at least 5 minutes between update attempts.
<29>1 2023-06-08T00:58:49+02:00 OPNsense.zuhause.xx ddclient[61106] 29212 - [meta sequenceId="1"] SUCCESS:  updating crandale.dedyn.io: good: IP address set to 87.XXX.XXX.140
<29>1 2023-06-08T01:03:49+02:00 OPNsense.zuhause.xx ddclient[61106] 50446 - [meta sequenceId="1"] WARNING:  skipping update of crandale.dedyn.io from <nothing> to 87.XXX.XXX.140.
<29>1 2023-06-08T01:03:49+02:00 OPNsense.zuhause.xx ddclient[61106] 50446 - [meta sequenceId="2"] WARNING:  last updated Thu Jun  8 00:58:49 2023 but last attempt on Thu Jun  8 00:58:49 2023 failed.

Could not yet find out why a SUCCESS for an update is noted in the logs which desec is not confirming.

I then tried the new python opnsense backend of ddclient and the result looks very encouraging:

I added simply two new lines into /usr/local/opnsense/scripts/ddclient/lib/account/dyndns2.py (line 37/38)

Code Select Expand


     35     _services = {
     36         'dyndns2': 'members.dyndns.org',
     37         'desec(v4)': 'update.dedyn.io',
     38         'desec(v6)': 'update6.dedyn.io',
     39         'dns-o-matic': 'updates.dnsomatic.com',


The configuration for desec and the opnsense backend look then like this:

- Services: Dynamic DNS: Settings: General Settings
Enabled [X]
Verbose [X]
Allow Ipv6 [X]
Interval [300]
Backend [OPNsense]

I added 2 services under the same desec account:

- Services: Dynamic DNS: Settings: Edit Account
Enabled [X]
Service [desec (v6)]
Protocol  [DynDNS2]
Username [Your Domain]
Password [Your DeSec Token]
Hostname(s) [Your Domain]
Check ip method [Interface [IPv6]]
Force SSL [X]
Interface to monitor [Your WAN Interface]

- Services: Dynamic DNS: Settings: Edit Account
Enabled [X]
Service [desec (v4)]
Protocol  [DynDNS2]
Username [Your Domain]
Password [Your DeSec Token]
Hostname(s) [Your Domain]
Check ip method [Interface [IPv4]]
Force SSL [X]
Interface to monitor [Your WAN Interface]

After activating, the ddclient logs look like

Code Select Expand


<165>1 2023-06-08T16:45:53+02:00 OPNsense.zuhause.xx ddclient 60835 - [meta sequenceId="4"] Account yyyyyyyyyy-18d2-47a7-b45a-4468975dc2e7 [desecv6 - dedyn]  set new ip 2003:XXXX:XXXX:XXXX:XXXX:efff:fe57:21ce [good]
<165>1 2023-06-08T16:45:53+02:00 OPNsense.zuhause.xx ddclient 60835 - [meta sequenceId="5"] Account yyyyyyyyy-18d2-47a7-b45a-4468975dc2e7 [desecv6 - dedyn]  changed
<165>1 2023-06-08T16:45:53+02:00 OPNsense.zuhause.xx ddclient 60835 - [meta sequenceId="6"] Account zzzzzzzzzz-f19d-4b4e-98a8-1bf71b62ee24 [desecv4 - dedyn]  execute
<163>1 2023-06-08T16:45:59+02:00 OPNsense.zuhause.xx ddclient 60835 - [meta sequenceId="7"] Account zzzzzzzzzz-f19d-4b4e-98a8-1bf71b62ee24 [desecv4 - dedyn]  failed to set new ip 87.XXX.XXX.236 [429 -
Request was throttled. Expected available in 55 seconds.]


After the mentioned 55sec, also the ipv4 address is visible at desec as an A record.

Means desec is bacically working on the new OPNsense backend for ipv4 AND ipv6 with some very simple and straight extensions to the dyndns.py code; only oddity is the throttling of the sequential request to the same desec account for v4 and v6 which allows obviously only one update per minute. Perhaps there is a possibility to add an additional throttling config item into the new opnsense backend code.

Several reboots and reconnects leading to different ipv4 and ipv6 addresses confirmed that it is working.

I think that this example could open potentially a pretty fast integration path for some more dyndns2 based service providers into the new opnsense backend python code and facilitate therewith at least in parts a catch up to the legacy dyndns solution as far as support of providers is concerned. Indeed there are many non dyndns2 providers for which more code needs to be written.

If this report is perceived positive perhaps it could be taken into the mainstream code base or you let me know how I could do this.

Br br

Hi all,

A while ago I changed my config and use a Draytek Vigor 167 directly connected to my opnsense. My provider ist Deutsche Telekom and I have a SuperVectoring connection. I configured a pppoe interface on vlan7 on WAN. Moreover, I created another interface on WAN called Modem to access the Vigor if needed. I get a ipv6 prefix from my supplier and the sense builds the corresponding ipv6 interface identifier (IID) out of the MAC addresses for the full ipv6 address. I have my LAN assigned to igb0 (Mac address Xc:XX:XX:XX:21:ce) and my WAN assigned to igb1 (Mac address Xc:XX:XX:XX:21:cf). So far all is fine and running.

However when looking into the dashboard and the interface overview, it is since then obvious that my LAN and WAN interface have an identical IID. Both IIDs are derived from the LAN MAC address. As a consequence, LAN and WAN have:

• the same link local address: fe80:XeXX:efff:XXXX:21ce
• the same IID for the public ipv6 address: 2003:<prefix_WAN>:XeXX:efff:XXXX:21ce resp 2003:<prefix_LAN>:XeXX:efff:XXXX:21ce

This looks weird to me. Is there an intention for this ipv6 address building logic? If not is there a need to get this corrected and if so I am wondering whether something could be wrong in my config? Is opnsense supporting privacy extensions for ipv6 meanwhile?

Looking forward to your reply.

Br br

Hi there,

after upgrading from 22.1.8_1 to 22.1.9 there is no access to the log files from GUI for some services. This affects in my case

dhcpd, unbound, system (backend), ACME,

The usual tricks (rebooting again manually, manual store config again , ...) did not change the situation. The GUI pages of the logs stay empty. NTP, system (general), system (webgui), firewall, routing can be viewed fine.

The log files as such are there an get updates as expected

Any idea how to analyse this further?

Looking forward to your reply

BR br

High there,

I upgraded just yesterday to 22.1 and everything went well and smooth, which once again make me very grateful for the excellent work the OPNSense team since years to make this possible. Thank you very much for that

More or less randomly I observed an issue now on the ipv6 address generation which I am not sure whether this is new or was already in the versions before:

My ISP is Telekom and I access my VDSL Dual Stack Super Vectoring access via Modem and PPPoE with configured VLAN 7 on the Sense. IPv6 Prefixes are generated out of WAN capturing with prefix IDs. With SLACC, the address (lower 64 Bits) part then is generated out of the MAC address as being specified in the RFC accordingly. So far so good.

I now observe, that in this configuration my WAN ipv6 address and my LAN IP v6 address differentiate indeed in the prefix, but the address parts are exactly the same on both interfaces. In Interfaces->Overview, the WAN MAC address ist shown as 00:00:..00; LAN MAC address corresponds to the physical one of my Hardware.

However, it seems now to be that the WAN ipv6 address generation on igb1 is using the MAC address of the LAN interface on igb0.

I am wondering whether this is intended as I consider this potentially as a security risk.

Does anyone has a similar observation?

Looking forward to your reply.

Br br

Hi,

I am going to rebuild my OPNsense installation using

     Draytek 167<-->Opnsense 21.7.4<-->(LAN) Gigaset GO Box 100; Provider is Telekom

No Fritz!Box, no sipproxd, the GO Box is directly connected to LAN. Everything is running so far, I implemented the outbound NAT rules (yes static ports is set  ;), Portforwardings (UDP) SIP and (UDP) RTP, WAN and LAN Firewall rules.

When you configure the GO Box, you have to this with the config wizard, select the Telekom profile and the Box is then configured. After that, the box registers and I can make calls, voice path OK. So far so good.

The problem is now that some time (between 10 and 60 min.), the box looses registration und can be brought back ro re-register only by deleting the complete connection setup and restart the config wizard. Then the device works for 10-60 min again.

Searching through different forum contribs, I have optimized:

- setting firewall optimization to conservative (ie NAT refresh) and set it on the Box to 10 sec
- setting SIP refresh from the suggested Telekom value of 600 to 300 sec
- exactly use the configured SIP port range from the Telekom profile also in NAT/FW rules (5060-5076)
- Reset all states when IP address changes is set


Has someone perhaps an advice for me what else to check?

Looking forward to any suggestions

Br br

Hi there,

I just wanted to expand a new domain with letsencrypt certificates via acme plugin (version 3.2) and noted that in acme client->settings->settings there is no switch anymore to change between staging and prod environment of letsencrypt for testing.

Has someone a recommendation how to change the environments now? Did I miss a fundamental change in logic for letsencrypt?

Looking forward to your reply..

Br br

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 Expand


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

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 Expand

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 Expand

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

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 Expand

Oct 17 10:54:33 OPNsense.zuhause.xx unbound[37717]: [37717:2] error: outgoing tcp: bind: Can't assign requested address
No 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 Expand

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 Expand

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

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

Thanks a lot

Br br

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 Expand

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

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

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 Expand


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

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 Expand


[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 Expand


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

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

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 Expand


[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

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 Expand


##------------------------------------------------------
## 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

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

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 ....