Topics

For quite some time now (months), I've been experiencing a "Page Unresponsive" message from Chrome when I try to refresh the dashboard after disuse. (I leave it logged in.) This is consistent and it takes approximately 2 minutes from when I refresh to when the message clears and the display actually refreshes.

I'm running OPNsense on a Windows Hyper-V Server 2022 and the client is Windows 10 Pro running on the same server. There are no other clients. The OPNsense VM has plenty of resources and the server is also not heavily loaded.

A screen capture is attached.

I changed internet service from VDSL to fibre recently and was reminded there is still a problem with OPNsense not being able to determine the IPV6 gateway address, resulting in the WAN_DHCP6 gateway not working unless the monitor IP address is manually set to the address of the gateway. When my service was upgraded, the IP address was still pointing at the address of the old gateway, which is no longer pingable. I cleared the address and rebooted to see if OPNsense could determine the address and it could not, so again, I had to manually set the address in gateway settings. I still have a pfSense system running and since it upgraded to BSD 14, it's having the same problem.

If there is anything I can do to help determine why this is happening, let me know.

I updated my test system from 21.7.r_210 to 21.7.r_228 and dpinger is not running. I can't start it from the dashboard and rebooting doesn't help. To be sure nothing had gotten corrupted, I restored to the r_210 checkpoint. The problem didn't exist. I upgraded it to r_228 again. dpinger worked until the first reboot, then after rebooting, it would not start again.

This is in the log:

/status_services.php: The WAN_DHCP6 IPv6 gateway address could not be found, skipping.   

Any suggestions?

I'm running 21.7.r_95 and accessing the GUI using a Windows 10 21H1 client on a hyper-v server using the latest version of chrome. Since updating OPNsense, when I leave the GUI overnight and refresh it the next day, the GUI is hung and chrome displays the message page unresponsive. This has happened several times since I updated. Usually, I just kill the chrome tab and open another one, which works fine.

Today, I left it running and looked more closely. Using the windows task manager, I saw that initially, the system interrupts background process was using 100% of the CPU. Later, this transitioned to the desktop window manager and chrome. After a few minutes, the GUI came back to life. I'm wondering if anyone else is experiencing this.

I just did a clean reinstall of 21.1. Normally, I prefer to display lease times in local time, not UTC. I found the DHCPv4 [LAN] settings in the usual place, but when I looked for the DHCPv6 settings, I noticed there is no page for [LAN] settings. Have these settings been moved somewhere else?

I have a couple of OPNsense VMs, one running the release version and the other running the development version. This morning, I tried to update the development version from the web user interface and encountered errors with the repository. I tried to update the release version with the web user interface and encountered similar errors. I've attached screen captures. Is there a problem with my systems?

I updated my development system to OPNsense 21.7.a_314. After the update, when I login to the console, it goes directly into shell mode. There are no obvious other problems. I've never encountered this before. Is this a known problem?

I'm running this version:

OPNsense 20.7.b_244-amd64
FreeBSD 11.2-RELEASE-p20-HBSD
OpenSSL 1.1.1g 21 Apr 2020

I updated using the following"

opnsense-update

This results in:

Nothing to do.

opnsense-code core

This result in the following:

Fetching origin
warning: Pulling without specifying how to reconcile divergent branches is
discouraged. You can squelch this message by running one of the following
commands sometime before your next pull:

  git config pull.rebase false  # merge (the default strategy)
  git config pull.rebase true   # rebase
  git config pull.ff only       # fast-forward only

You can replace "git config" with "git config --global" to set a default
preference for all repositories. You can also pass --rebase, --no-rebase,
or --ff-only on the command line to override the configured default per
invocation.

Already up to date.
ABI 20.1 is no longer supported
Fetching origin
warning: Pulling without specifying how to reconcile divergent branches is
discouraged. You can squelch this message by running one of the following
commands sometime before your next pull:

  git config pull.rebase false  # merge (the default strategy)
  git config pull.rebase true   # rebase
  git config pull.ff only       # fast-forward only

You can replace "git config" with "git config --global" to set a default
preference for all repositories. You can also pass --rebase, --no-rebase,
or --ff-only on the command line to override the configured default per
invocation.

Already up to date.

What is the recommended next step?

I updated my test system and after it restarted, dhcpd6 was not running and would not start. It was a while since I last updated it, so I bootstrapped to a previous version which does not have the problem, then updated to see if the problem returned.

After bootstrapping, here is the version:

OPNsense 20.1.6-amd64
FreeBSD 11.2-RELEASE-p19-HBSD
OpenSSL 1.1.1g 21 Apr 2020

This version works properly.

After updating from the GUI, here is the version:

OPNsense 20.7.b_97-amd64
FreeBSD 11.2-RELEASE-p19-HBSD
OpenSSL 1.1.1g 21 Apr 2020

This version works properly.

After updating from the command line (opnsense-update, opnsense-code core, make upgrade), here is the version:

OPNsense 20.7.b_156-amd64
FreeBSD 11.2-RELEASE-p19-HBSD
OpenSSL 1.1.1g 21 Apr 2020

With this version, dhcpd6 will not start and the Windows 10 client cannot get an IPv6 address.

The only related message in the log is this:

Code Select Expand

opnsense-devel: /usr/local/etc/rc.bootup: Warning! dhcpd_dhcp6_configure() found no suitable IPv6 address on lan

My ISP requires the use of the "Directly send SOLICIT" setting, which appears to be missing.

I have an OPNsense installation running with release type development. The version is OPNsense 20.1.r_6-amd64.

If I check for updates, two choices are offered. The first choice consists of 32 updates, including downgrading the base from 20.1 to 19.7, upgrading some packages, reinstalling some packages and removing some packages, including opnsense-devel. The other choice is to unlock 20.1.r1.

If I select the first choice, this message appears in the log

Code Select Expand

***GOT REQUEST TO UPGRADE: all***
Updating OPNsense repository catalogue...
OPNsense repository is up to date.
All repositories are up to date.
Updating OPNsense repository catalogue...
OPNsense repository is up to date.
All repositories are up to date.
Checking for upgrades (29 candidates): .......... done
Processing candidates (29 candidates): .......... done
Checking integrity... done (1 conflicting)
  - openssl102-1.0.2u conflicts with openssl-1.1.1d,1 on /usr/local/bin/c_rehash
Cannot solve problem using SAT solver, trying another plan
Checking integrity... done (0 conflicting)
The following 30 package(s) will be affected (of 0 checked):

Installed packages to be REMOVED:
opnsense-update-20.1
opnsense-devel-20.1.r_6
openssl-1.1.1d,1

New packages to be INSTALLED:
openssl102: 1.0.2u

Installed packages to be UPGRADED:
py37-urllib3: 1.25.6,1 -> 1.25.7,1
py37-setuptools: 41.4.0_1 -> 44.0.0
liblz4: 1.9.2,1 -> 1.9.2_1,1
isc-dhcp44-server: 4.4.1_4 -> 4.4.2
isc-dhcp44-relay: 4.4.1 -> 4.4.2

Installed packages to be REINSTALLED:
wpa_supplicant-2.9 (options changed)
unbound-1.9.6 (direct dependency changed: openssl102)
syslog-ng325-3.25.1 (direct dependency changed: openssl102)
strongswan-5.8.2_1 (direct dependency changed: openssl102)
squid-4.9 (direct dependency changed: krb5)
python37-3.7.6 (direct dependency changed: openssl102)
py37-cryptography-2.6.1 (direct dependency changed: openssl102)
php72-openssl-7.2.26 (direct dependency changed: openssl102)
openvpn-2.4.8 (direct dependency changed: openssl102)
openssh-portable-8.1.p1,1 (direct dependency changed: openssl102)
openldap-sasl-client-2.4.48 (direct dependency changed: cyrus-sasl)
ntp-4.2.8p13_6 (direct dependency changed: openssl102)
mpd5-5.8_10 (direct dependency changed: openssl102)
monit-5.26.0 (direct dependency changed: openssl102)
lighttpd-1.4.54 (direct dependency changed: openssl102)
libevent-2.1.11 (direct dependency changed: openssl102)
ldns-1.7.1_1 (direct dependency changed: openssl102)
krb5-1.17.1 (direct dependency changed: openssl102)
hostapd-2.9 (direct dependency changed: openssl102)
cyrus-sasl-2.1.27_1 (direct dependency changed: openssl102)
curl-7.68.0 (direct dependency changed: ca_root_nss)

Number of packages to be removed: 3
Number of packages to be installed: 1
Number of packages to be upgraded: 5
Number of packages to be reinstalled: 21

The operation will free 22 MiB.
pkg-static: Cannot delete vital package: opnsense-devel!
pkg-static: If you are sure you want to remove opnsense-devel,
pkg-static: unset the 'vital' flag with: pkg set -v 0 opnsense-devel
Starting web GUI...done.
Generating RRD graphs...done.
***DONE***

Note the end where it says the following:

pkg-static: Cannot delete vital package: opnsense-devel!
pkg-static: If you are sure you want to remove opnsense-devel,
pkg-static: unset the 'vital' flag with: pkg set -v 0 opnsense-devel

Is this expected behaviour or does my system have a problem?

Just so this doesn't get left behind, I reinstalled OPNsense from scratch on my windows server 2019 hyper-v and I experienced the same freezing as in the previous version. The first time was at the point of selecting guided setup. At this point, I interrupted using CTRL-C and logged in again as installer. It happened once or twice again further on. I'm using a generation 2 vm with secure boot disabled. The settings are default.

If you would like me to test anything, let me know.

I updated my release system to 19.7 today. There are two problems, which were both present in the pre-release versions.

The firmware reporter is reporting, "Unfortunately we have detected at least one programming bug."

Here is the error:

Code Select Expand

[28-Jul-2019 11:37:05 America/Vancouver] PHP Warning:  vsprintf(): Too few arguments in /usr/local/etc/inc/util.inc on line 986

The other problem is that Gateway Monitor (WAN_DHCP6) is not starting. There are no errors in any of the logs that appear to be related to this problem (although it could be that I'm not looking in the right place for the smoking gun). There is only one instance of dpinger running and that is for WAN_DHCP.

I also noticed that every time I try to start the gateway monitor, another instance of the above PHP warning is issued.

My offer still stands to make the system available for someone to take a look at.

My ISP has an issue with some of their edge routers where they are not sending periodic unsolicited RA messages. This is happening with their Juniper edge routers. For their Alcatel/Nokia edge routers, unsolicited RA messages are sent every 20-30 minutes. The Juniper edge routers will respond to RS messages.

I'm not sure how this behaviour started. It may be that Juniper or one of their customers decided it was a feature. However, recently, Juniper started offering "no unsolicited ra" as selectable "Enhanced Subscriber Management feature". Here is a link: https://www.juniper.net/documentation/en_US/junos/topics/reference/configuration-statement/no-unsolicited-ra-edit-enhanced-universal-edge-overrides.html.

The behaviour of the other *sense is inconsistent. Sometimes IPv6 will drop after 2 hours. If you save / apply the WAN I/F, it will restart. Other times, it will continue to work.

What is the behaviour of OPNsense if the edge router doesn't send an unsolicited RA? Is there a way to trigger OPNsense to send a solicited RS message for situations such as this? I would try this myself, but it's working properly for me.

I had to rebuild my hyper-v server, so I did a clean installation of OPNsense using the latest download, which is OPNsense-19.1.4-OpenSSL-dvd-amd64.iso. I created a generation 2 VM with secure boot disabled, two processors and 2048 of memory. On both NICs, VMQ, IPsec task offloading (512) and SR-IOV are enabled and all of the "advanced features" are disabled. Both NICS are connected to virtual switches.

I had to use CTRL-C a couple of times during the installation because the installer hung.

Aside from that, the installation was successful.

I'm running OPNsense 19.7.a_516-amd64. I noticed a LAN_TRACK6 gateway with unknown status on the dashboard and pending status on the gateway status. I have never noticed this gateway before. The client has an IPV6 lease and IPv6 seems to be working properly.

Does anyone know what this gateway is for and why it has unknown / pending status?

If you've never heard of the Atlas project, here is a link: https://atlas.ripe.net/.

Here is some information:

With your help, the RIPE NCC is building the largest Internet measurement network ever made. RIPE Atlas employs a global network of probes that measure Internet connectivity and reachability, providing an unprecedented understanding of the state of the Internet in real time.

The project is looking for people to host probes that will help to fill in gaps in the coverage. I believe they prefer dual-stack, but it probably depends on the situation. I got one of the probes a few weeks ago and it's interesting to see the information it's providing to the project. The probe is very small. I comes with a USB power supply, but I'm powering my probe with a USB port on one of my servers. If you're interested in contributing, it's very easy to apply for a probe.

Does OPNsense have a command prompt, like pfSense Diagnostics / Command Prompt?

I'm currently running 19.7a_39. Trying to update but can't get make upgrade to complete.

Here is the shell output:

Code Select Expand

root@OPNsense:/usr # rm -rf core
root@OPNsense:/usr # opnsense-code core
Cloning into '/usr/core'...
remote: Enumerating objects: 189, done.
remote: Counting objects: 100% (189/189), done.
remote: Compressing objects: 100% (124/124), done.
remote: Total 120845 (delta 101), reused 119 (delta 57), pack-reused 120656
Receiving objects: 100% (120845/120845), 64.08 MiB | 2.04 MiB/s, done.
Resolving deltas: 100% (86578/86578), done.
root@OPNsense:/usr # cd core
root@OPNsense:/usr/core # make upgrade
pkg: No package(s) matching squid
Updating OPNsense repository catalogue...
OPNsense repository is up to date.
All repositories are up to date.
pkg: No packages available to install matching 'squid' have been found in the repositories
*** Error code 70

Stop.
make: stopped in /usr/core
root@OPNsense:/usr/core #


Any suggestions?

I have two opnsense systems, both running on windows server 2012r2 hyper-v. One system is running the latest release and the other is running 19.1b. I've noticed on both systems that the ntp service is taking longer to start up after rebooting than it used to. Both systems are using the default ntp settings.

I took a look at the status and I have some questions.

Here are the messages in the log, beginning after restarting the ntp service:

Dec 15 09:13:09   ntpd[84257]: kernel reports TIME_ERROR: 0x41: Clock Unsynchronized
Dec 15 09:13:09   ntpd[84257]: kernel reports TIME_ERROR: 0x41: Clock Unsynchronized
Dec 15 09:13:09   ntpd[84257]: mlockall(): Cannot allocate memory
Dec 15 09:13:09   ntpd[84257]: Listening on routing socket on fd #26 for interface updates
Dec 15 09:13:09   ntpd[84257]: Listen normally on 5 hn0 162.156.75.11:123
Dec 15 09:13:09   ntpd[84257]: Listen normally on 4 hn0 [fe80::215:5dff:fe5c:e233%5]:123
Dec 15 09:13:09   ntpd[84257]: Listen normally on 3 lo0 127.0.0.1:123
Dec 15 09:13:09   ntpd[84257]: Listen normally on 2 lo0 [::1]:123Dec 15 09:13:09   ntpd[84257]: Listen and drop on 1 v4wildcard 0.0.0.0:123
Dec 15 09:13:09   ntpd[84257]: Listen and drop on 0 v6wildcard [::]:123
Dec 15 09:13:09   ntpd[84257]: restrict: 'monitor' cannot be disabled while 'limited' is enabled
Dec 15 09:13:09   ntpd[84257]: proto: precision = 0.100 usec (-23)
Dec 15 09:13:09   ntpd[84036]: Command line: /usr/local/sbin/ntpd -g -c /var/etc/ntpd.conf -p /var/run/ntpd.pid
Dec 15 09:13:09   ntpd[84036]: ntpd 4.2.8p12@1.3728-o Mon Sep 17 00:37:07 UTC 2018 (1): Starting
Dec 15 09:13:09   ntpd[77483]: 206.108.0.134 local addr 162.156.75.11 -> <null>
Dec 15 09:13:09   ntpd[77483]: 2001:6a0:0:31::2 local addr fe80::215:5dff:fe5c:e233%5 -> <null>
Dec 15 09:13:09   ntpd[77483]: 162.248.221.109 local addr 162.156.75.11 -> <null>
Dec 15 09:13:09   ntpd[77483]: 54.39.173.225 local addr 162.156.75.11 -> <null>
Dec 15 09:13:09   ntpd[77483]: ntpd exiting on signal 15 (Terminated)

One of the message refers to memory. The system is currently using only 20% of memory.

Also, it appears that one of the default servers is not reachable. Refer to the screen capture.

I have two opnsense systems, both running on windows server 2012r2 hyper-v. One system is running the latest release and the other is running 19.1b. Yesterday, I updated both of them and now dhcpd6 is broken on both of them.

My ISP provides a /56 prefix. I also have two other *sense systems running on the same hyper-v server. Both are working properly, so I don't think this issue is related to my ISP.

Here is a message from the general log:

opnsense: /usr/local/etc/rc.newwanipv6: The command '/usr/local/sbin/dhcpd -6 -user dhcpd -group dhcpd -chroot /var/dhcpd -cf /etc/dhcpdv6.conf -pf /var/run/dhcpdv6.pid hn1' returned exit code '1', the output was 'Internet Systems Consortium DHCP Server 4.4.1 Copyright 2004-2018 Internet Systems Consortium. All rights reserved. For info, please visit https://www.isc.org/software/dhcp/ /etc/dhcpdv6.conf line 15: network mask too short prefix6 2001:560:74b0:2800:: 2001:560:74b0:2800::/48; ^ Configuration file errors encountered -- exiting If you think you have received this message due to a bug rather than a configuration issue please read the section on submitting bugs on either our web page at www.isc.org or in the README file before submitting a bug. These pages explain the proper process and the information we find helpful for debugging. exiting.'

Note, the message is referring to /48. Not sure where that comes from.