Menu

Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Show posts Menu

Messages - clarknova

#1
Yes, things are working much smoother with the plugin now available from a standard install.
#2
General Discussion / Re: Unable to upgrade from 22.1
March 24, 2025, 07:02:45 PM
Thanks for the replies. I didn't set up this pair and I wasn't aware FreeBSD repos were enabled. I was under pressure to complete the upgrade so I ended up booting the VMs from the 25.1 ISO and did a fresh install after importing the config file. I then upgraded to 25.1.3 and was able to reinstall the plugins with a good outcome.

If I see this again in the future I will try disabling the extra repos.
#3
OPNsense 25.1.3
os-theme-advanced 1.0_1

What's the best place to report a bug in this theme package? I see the package maintainer's email address in the package info, but I don't want to email somebody directly if there's a bug tracker set up somewhere.

I see there is a bug report on OPNsense's github, but it was closed as stale and I wonder if the maintainer doesn't look there.

https://github.com/opnsense/plugins/issues/4207
#4
I inherited a pair of firewalls running OPNsense 23.1.4_1. When I try upgrading from console or web, I get the error "Missing /usr/local/etc/pkg/repos/OPNsense.conf". I tried opnsense-bootstrap from the shell and I got this:

Bootstrapping pkg from pkg+http://pkg.FreeBSD.org/FreeBSD:13:amd64/quarterly, please wait...
Verifying signature with trusted certificate pkg.freebsd.org.2013102301... done
Installing pkg-1.21.3...
package pkg is already installed, forced install
Extracting pkg-1.21.3: 100%
Updating FreeBSD repository catalogue...
FreeBSD repository is up to date.
All repositories are up to date.
Updating database digests format: 100%
Checking integrity... done (0 conflicting)
The most recent versions of packages are already installed
fetch: https://github.com/opnsense/core/archive/stable/23.1.tar.gz: size of remote file is not known
/tmp/opnsense-bootstrap/core.tar.gz                   7624 kB 7826 kBps    01s
pkg: 146 packages installed
beep-1.0_1: already unlocked

Is there a way to get opnsense-bootstrap working or am I stuck doing a reinstall from iso?
I also tried opnsense-bootstrap -r 25.1 and it was similarly ineffictive.
#5
It's not just the default pass out rule. All of the rules in this attached screenshot are pass rules.
#6
Since upgrading to 25.1.1 (we didn't spend any time on 25.1) I'm seeing log entries that are unexpected for two reasons:

  • The entry indicates a block, but the rule description indicates a pass.
  • The indicated rule is not configured to be logged.

I didn't see these log entries on 24.7. Is this an expected change of behaviour?
#7
General Discussion / Unable to upgrade from 22.1
January 15, 2025, 05:52:45 PM
I was tasked today with upgrading a remote firewall that was running OPNsense 21.7.8. I upgraded to 22.1 in the web UI and it upgraded and rebooted without error. Now while trying to upgrade past 22.1 I get errors.

From web UI:
***GOT REQUEST TO CHECK FOR UPDATES***
Currently running OPNsense 22.1 (amd64/OpenSSL) at Wed Jan 15 09:40:23 MST 2025
Fetching changelog information, please wait... Missing /usr/local/etc/pkg/repos/OPNsense.conf
Repository not found: OPNsense
Updating FreeBSD repository catalogue...
Fetching meta.conf: . done
Fetching data.pkg: .......... done
Processing entries:
Newer FreeBSD version for package zziplib:
To ignore this error set IGNORE_OSVERSION=yes
- package: 1304000
- running kernel: 1300523
Ignore the mismatch and continue? [y/N]: pkg: repository FreeBSD contains packages for wrong OS version: FreeBSD:13:amd64
Processing entries...
Unable to update repository FreeBSD
Error updating repositories!
pkg: Unknown repository: OPNsense
***DONE***

From shell:
# opnsense-update -u
Missing /usr/local/etc/pkg/repos/OPNsense.conf

# opnsense-bootstrap
This utility will attempt to turn this installation into the latest
OPNsense 22.1 release.  All packages will be deleted, the base
system and kernel will be replaced, and if all went well the system
will automatically reboot.

Proceed with this action? [y/N]: y
Bootstrapping pkg from pkg+http://pkg.FreeBSD.org/FreeBSD:13:amd64/latest, please wait...
Verifying signature with trusted certificate pkg.freebsd.org.2013102301... done
Installing pkg-1.21.3...
package pkg is already installed, forced install
Extracting pkg-1.21.3: 100%
Updating FreeBSD repository catalogue...
FreeBSD repository is up to date.
All repositories are up to date.
Updating database digests format: 100%
Checking integrity... done (0 conflicting)
The most recent versions of packages are already installed
/tmp/opnsense-bootstrap/core.tar.gz                   7508 kB 9443 kBps    01s
pkg: 139 packages installed
beep-1.0_1: already unlocked

I also tried a health check from the GUI:
***GOT REQUEST TO AUDIT HEALTH***
Currently running OPNsense 22.1 (amd64/OpenSSL) at Wed Jan 15 09:46:54 MST 2025
>>> Check installed kernel version
Version 22.1 is correct.
Unverified consistency check for kernel: invalid /usr/local/opnsense/version/kernel.mtree.sig
>>> Check for missing or altered kernel files
No problems detected.
>>> Check installed base version
Version 22.1 is correct.
Unverified consistency check for base: invalid /usr/local/opnsense/version/base.mtree.sig
>>> Check for missing or altered base files
No problems detected.
>>> Check for missing package dependencies
Checking all packages: .......... done
>>> Check for missing or altered package files
Checking all packages:
ca_root_nss-3.104: checksum mismatch for /etc/ssl/cert.pem
Checking all packages.......
opnsense-22.1: missing file /usr/local/etc/pkg/fingerprints/OPNsense/revoked/pkg.opnsense.org.20150402
opnsense-22.1: missing file /usr/local/etc/pkg/fingerprints/OPNsense/revoked/pkg.opnsense.org.20160104
opnsense-22.1: missing file /usr/local/etc/pkg/fingerprints/OPNsense/revoked/pkg.opnsense.org.20160630
opnsense-22.1: missing file /usr/local/etc/pkg/fingerprints/OPNsense/revoked/pkg.opnsense.org.20161210
opnsense-22.1: missing file /usr/local/etc/pkg/fingerprints/OPNsense/revoked/pkg.opnsense.org.20170625
opnsense-22.1: missing file /usr/local/etc/pkg/fingerprints/OPNsense/revoked/pkg.opnsense.org.20171219
opnsense-22.1: missing file /usr/local/etc/pkg/fingerprints/OPNsense/revoked/pkg.opnsense.org.20180614
opnsense-22.1: missing file /usr/local/etc/pkg/fingerprints/OPNsense/revoked/pkg.opnsense.org.20181218
opnsense-22.1: missing file /usr/local/etc/pkg/fingerprints/OPNsense/revoked/pkg.opnsense.org.20190702
opnsense-22.1: missing file /usr/local/etc/pkg/fingerprints/OPNsense/revoked/pkg.opnsense.org.20200119
opnsense-22.1: missing file /usr/local/etc/pkg/fingerprints/OPNsense/revoked/pkg.opnsense.org.20200313
opnsense-22.1: missing file /usr/local/etc/pkg/fingerprints/OPNsense/revoked/pkg.opnsense.org.20210104
opnsense-22.1: missing file /usr/local/etc/pkg/fingerprints/OPNsense/trusted/pkg.opnsense.org.20210629
opnsense-22.1: missing file /usr/local/etc/pkg/fingerprints/OPNsense/trusted/pkg.opnsense.org.20210903
opnsense-22.1: missing file /usr/local/etc/pkg/repos/FreeBSD.conf.sample
opnsense-22.1: missing file /usr/local/etc/pkg/repos/OPNsense.conf.sample
Checking all packages......... done
>>> Check for core packages consistency
Core package "opnsense" has 65 dependencies to check.
Checking packages: .
beep-1.0_1 has no upstream equivalent
Checking packages: .
ca_root_nss-3.104 repository mismatch: FreeBSD
ca_root_nss-3.104 has no upstream equivalent
Checking packages: .
choparp-20150613 has no upstream equivalent
Checking packages: .
cpustats-0.1 has no upstream equivalent
Checking packages: .
dhcp6c-20200512_1 has no upstream equivalent
Checking packages: .
dhcpleases-0.2 has no upstream equivalent
Checking packages: .
dnsmasq-2.86_2,1 has no upstream equivalent
Checking packages: .
dpinger-3.0 has no upstream equivalent
Checking packages: .
expiretable-0.6_2 has no upstream equivalent
Checking packages: .
filterlog-0.6 has no upstream equivalent
Checking packages: .
flock-2.37.2 has no upstream equivalent
Checking packages: .
flowd-0.9.1_3 has no upstream equivalent
Checking packages: .
hostapd-2.10 has no upstream equivalent
Checking packages: .
ifinfo-13.0 has no upstream equivalent
Checking packages: .
iftop-1.0.p4 has no upstream equivalent
Checking packages: .
isc-dhcp44-relay-4.4.2P1 has no upstream equivalent
Checking packages: .
isc-dhcp44-server-4.4.2P1_1 has no upstream equivalent
Checking packages: .
lighttpd-1.4.63 has no upstream equivalent
Checking packages: .
monit-5.29.0_1 has no upstream equivalent
Checking packages: .
mpd5-5.9_6 has no upstream equivalent
Checking packages: .
ntp-4.2.8p15_4 has no upstream equivalent
Checking packages: .
openssh-portable-8.8.p1_1,1 has no upstream equivalent
Checking packages: .
openssl-1.1.1m_1,1 has no upstream equivalent
Checking packages: .
openvpn-2.5.5 has no upstream equivalent
Checking packages: .
opnsense-22.1 has no upstream equivalent
Checking packages: .
opnsense-installer-22.1 has no upstream equivalent
Checking packages: .
opnsense-lang-21.7.8 has no upstream equivalent
Checking packages: .
opnsense-update-22.1 has no upstream equivalent
Checking packages: .
pam_opnsense-19.1.3 has no upstream equivalent
Checking packages: .
pftop-0.7_9 has no upstream equivalent
Checking packages: .
php74-ctype-7.4.27 has no upstream equivalent
Checking packages: .
php74-curl-7.4.27 has no upstream equivalent
Checking packages: .
php74-dom-7.4.27 has no upstream equivalent
Checking packages: .
php74-filter-7.4.27 has no upstream equivalent
Checking packages: .
php74-gettext-7.4.27 has no upstream equivalent
Checking packages: .
php74-google-api-php-client-2.4.0 has no upstream equivalent
Checking packages: .
php74-json-7.4.27 has no upstream equivalent
Checking packages: .
php74-ldap-7.4.27 has no upstream equivalent
Checking packages: .
php74-openssl-7.4.27 has no upstream equivalent
Checking packages: .
php74-pdo-7.4.27 has no upstream equivalent
Checking packages: .
php74-pecl-radius-1.4.0b1_1 has no upstream equivalent
Checking packages: .
php74-phalcon4-4.1.3 has no upstream equivalent
Checking packages: .
php74-phpseclib-2.0.35 has no upstream equivalent
Checking packages: .
php74-session-7.4.27 has no upstream equivalent
Checking packages: .
php74-simplexml-7.4.27 has no upstream equivalent
Checking packages: .
php74-sockets-7.4.27 has no upstream equivalent
Checking packages: .
php74-sqlite3-7.4.27 has no upstream equivalent
Checking packages: .
php74-xml-7.4.27 has no upstream equivalent
Checking packages: .
php74-zlib-7.4.27 has no upstream equivalent
Checking packages: .
pkg-1.21.3 repository mismatch: unknown-repository
pkg-1.21.3 has no upstream equivalent
Checking packages: .
py38-Jinja2-3.0.1 has no upstream equivalent
Checking packages: .
py38-dnspython2-2.2.0 has no upstream equivalent
Checking packages: .
py38-netaddr-0.8.0 has no upstream equivalent
Checking packages: .
py38-requests-2.25.1 has no upstream equivalent
Checking packages: .
py38-sqlite3-3.8.12_7 has no upstream equivalent
Checking packages: .
py38-ujson-5.0.0 has no upstream equivalent
Checking packages: .
radvd-2.19_1 has no upstream equivalent
Checking packages: .
rrdtool-1.7.2_4 has no upstream equivalent
Checking packages: .
samplicator-1.3.8.r1_1 has no upstream equivalent
Checking packages: .
squid-4.15 has no upstream equivalent
Checking packages: .
strongswan-5.9.4 has no upstream equivalent
Checking packages: .
sudo-1.9.8p2 has no upstream equivalent
Checking packages: .
suricata-6.0.4_1 has no upstream equivalent
Checking packages: .
syslog-ng-3.35.1 has no upstream equivalent
Checking packages: .
unbound-1.14.0 has no upstream equivalent
Checking packages: .
wpa_supplicant-2.10 has no upstream equivalent
Checking packages: .
zip-3.0_1 has no upstream equivalent
***DONE***

Where do I go from here? I'm off site, so any remote rescue option is preferred at this point and the firewall is still running and accesscible. If I brick the thing I can get remote hands, but I'd prefer not to delegate a fresh install from USB if I can avoid it.
#8
To reproduce (tested on OPNsene 24.7.9_1 and Windows NPS):

  • Configure a pair of OPNsense hosts in HA and set "Auth Servers" to sync in System: High Availability: Settings
  • Configure a RADIUS server in System: Access: Servers
  • Configure a RADIUS server and add both OPNsense hosts as clients
  • Synchronise config to backup in System: High Availability: Status
  • Attempt to log into configuration master with a RADIUS account, then into the peer

Result:
The RADIUS logs will show two login attempts, one from each client, and both with identical NAS Identifier. Even if the first login attempt is successful, the second one will fail due to the duplicated NAS ID.

Expected Result:
If I use HA/XMLRPC sync to keep my Authentication Server settings synchronised between two hosts, the NAS ID should not be copied.

Recommended Change:
The second peer should have some mechanism to generate its own unique NAS ID if a RADIUS server is created by XMLRPC sync.
#9
I have my RADIUS server set to automatically create users. This works fine, except the user is created with a shell of /usr/sbin/nologin Is there a way to make this something different so a new user can log in via SSH without first having to log into the web UI and change the shell?
#10
24.7, 24.10 Legacy Series / Re: RADIUS WITH WINDOWS NPS
November 29, 2024, 11:16:09 PM
QuoteThe reason I say it's only kind of working is that when I try logging in with the user, I get the error: "No page assigned to this user! Click here to log out."

I finally got this working. Pro tip: don't copy an existing rule. Even if all the settings look correct, it doesn't work until the rule is created.

I finally got the same error as you. On the NPS policy Settings tab, instead of Class = admins, try Class = CN=admins. This worked for me.
#11
24.7, 24.10 Legacy Series / Re: RADIUS WITH WINDOWS NPS
November 29, 2024, 09:56:00 PM
hm, I removed the User Groups condition and re-added it and now the NPS log shows access granted, but my OPNsense tester still shows failed. I think it's not understanding the server's response. The System General log shows "Radius unexpected response:"
#12
24.7, 24.10 Legacy Series / Re: RADIUS WITH WINDOWS NPS
November 29, 2024, 09:43:06 PM
You got further than I did. Did you add any RADIUS attributes to your network policy? I can't get my authentication requests from OPNsense to match my policy, and I'm using the same two conditions that are working on a couple of Juniper and Arista policies (User Groups and Client Friendly Name).
#13
I discovered another pass rule on the ingress interface that was passing the packets in question, so they never matched the first rule. That explains how they were caught by the egress rule on the WAN, which did its job.
#14
I can make the first rule quick and move it to the bottom of the every interface's ruleset, but this is less elegant and leaves two questions unanswered.

  • How can the first rule operate on a packet at egress before the second rule operates on the same packet at ingress?
  • Why are some packets dropped by the second rule while others are not? I have verified this by enabling logging on the second rule.
#15
OPNsense 24.7.7

This firewall host has a WAN interface (lagg0_vlan17) with a publicly routable IPv4 address and multiple LAN interfaces. I created a floating rule to prevent packets with rfc5735 (local and invalid) destination addresses from being leaked on to the internet. I also created an outbound rule on the WAN as a last-resort catch-all rule for the same purpose. These two rules look like this:

block return in inet from any to <rfc5735> label "c66bd7ebe022fedb2fdd2d7bdfbf7ee5"
block drop out log quick on lagg0_vlan17 inet from any to <rfc5735> label "f8905c704b9481e346fca8eebfa98578"


To my surprise, I'm seeing packets logged by the second rule. I believed that packets would be evaluated against 'in' rules as they entered an interface, and against 'out' rules as they exited an interface. If this assumption is correct, then only packets originating from the firewall itself should match the second rule, as any packets from local hosts should have matched the first rule at ingress and been dropped. Yet I'm seeing packets in the log that did not originate from the firewall. So what have I got wrong?