NethSecurity 8.8.0 Beta2 ready for testing!

davide_marini · July 7, 2026, 10:51am

We are pleased to announce the release of NethSecurity-8.8.0-beta.2.

This version is a major platform update: NethSecurity 8.8.0 is based on OpenWrt 25.12, while version 8.7.2 was based on 24.10.

The rebase introduces significant updates to the system, kernel, main networking and VPN components, as well as numerous security fixes.

We need you

We need to test the beta in as many scenarios as possible and collect as much feedback as possible.
Only after that will we be able to proceed with the stable release.

Since this is a beta, use in critical production environments is not recommended.

Download and try NethSecurity-8.8.0-beta.2

Controller compatibility

Using NethSecurity-8.8.0-beta.2 with Controller requires at least Controller version 2.2.7-dev.3.

At this stage, however, we do not recommend upgrading Controllers used in production: after upgrading to the version required by the beta, firewalls running stable versions of NethSecurity may no longer be accessible from the Controller.

Before upgrading the Controller or connecting a firewall to the beta, make sure the environment is intended for testing or evaluation and does not manage production devices.

Beta highlights

NethSecurity-8.8.0-beta.2 introduces a major update to the system base.

This includes:

update of the Linux kernel to version 6.12
update of many system and networking components
switch from the opkg package manager to the new apk package manager
update of OpenVPN to version 2.7.4
update of IPsec/strongSwan to version 6.0.3
numerous vulnerabilities fixed in base components, the kernel, network services and system libraries
general improvements in stability, compatibility and hardware support

The new package manager is one of the most relevant changes: apk replaces opkg as the package management system.

For users who only use the web interface, the impact should be minimal, while those who install or manage packages from the CLI will need to take the new command syntax into account.

This beta allows us to validate the behavior of the new system base in real-world scenarios, with configurations and installations different from those covered by internal tests.

What’s new

Integrated native metrics

NethSecurity introduces a new section of natively managed metrics, integrated directly into the firewall interface.

The new section allows you to view information on many aspects of system operation, including:

network traffic
firewall load
interface trends
latency graphs
useful indicators to check the overall status of the appliance

Some of this information was already available through Netdata, but it is now integrated directly into the NethSecurity UI, making consultation more immediate and providing higher retention.

If storage is configured, metrics retention reaches up to 52 weeks.

Alerts and notifications

A new section dedicated to alerts and notifications has been introduced, designed to inform the administrator in case of firewall anomalies or relevant conditions.

This feature provides greater visibility into system status and allows faster action when events requiring attention are detected.

Geoblocking in Threat Shield IP

The Threat Shield IP section introduces the ability to manage IP geoblocking directly from the firewall interface.

It is now possible to apply geoblocking rules, allowing more flexible management of policies based on the geographic origin or destination of IP addresses.
Blocking is active only for inbound traffic, blocking all requests from the internet while allowing hosts on the network to browse freely.

DHCP server with multiple ranges

The new UI allows you to specify multiple IP ranges for the same DHCP server. This simplifies configuration in environments where the network includes a mix of devices with static and dynamic IP addresses.

Emergency CLI tool

The new beta also introduces a CLI configuration tool, designed for emergency situations where it is not possible to access the firewall web interface.

By accessing the system via console or SSH and running the setup command, it is possible to open a text-based menu that allows basic network configuration to be modified without using the browser UI.

The tool allows you to:

configure the LAN interface
configure the WAN interface
modify the IPv4 address and interface protocol
apply network changes
modify the console keyboard layout

This feature is especially intended for cases where an incorrect network configuration makes the web UI unreachable, or when working directly from the local console during installation, recovery or troubleshooting.

Management of additional packages and image updates

Management of manually installed additional packages has been improved, an especially important aspect in this version due to the switch to the new apk package manager.

The goal is to make the behavior of additional packages more reliable in image update scenarios and customized installations.

DHCP lease persistence on mounted storage

On appliances with configured storage, DHCP leases are preserved even in case of shutdown.

This change is useful in scenarios where maintaining DHCP lease status after reboots or updates is desired, improving service continuity in networks where address assignment is particularly important.

Avahi / mDNS support

The Avahi (mDNS) package has been added to the NethSecurity repositories.

This makes it possible to enable local discovery scenarios based on mDNS, useful for example for devices, services or environments where automatic discovery of resources on the local network is required.

New firewall action “NOTRACK”

A new action has been introduced in firewall rules: NOTRACK.

This action allows specific traffic to be excluded from connection tracking, useful in advanced scenarios where you want to reduce load or manage certain network flows in a more targeted way.

OpenVPN updated

OpenVPN moves to version 2.7.4.

The update introduces a more recent base for roadwarrior and site-to-site VPNs based on OpenVPN.

Since this is a major version jump, we invite those who use OpenVPN to try the beta and report any anomalies with existing configurations, legacy clients, certificates, ciphers or custom options.

IPsec updated

The IPsec engine, based on strongSwan, moves to version 6.0.3.

This is also an important update, requiring broad validation on real-world scenarios: site-to-site tunnels, configurations with multiple networks, route-based VPNs, configurations with certificates, PSKs and interoperability scenarios with firewalls from other vendors.

We especially invite those who use IPsec in production to test the beta in a lab environment and share feedback.

New log management for bruteforce control

The component that analyzes logs looking for bruteforce attempts now works on a dedicated log file and monitors only the services typically affected by this type of control:

OpenVPN
Dropbear
API server

It is important to know that any custom regexps will only be applied to the logs of these services.

More features available in the community version

Starting with NethSecurity-8.8.0-beta.2, some features previously reserved for installations with an active subscription are now also available in the community version.

The following actions, previously visible but not clickable, can now be used:

ability to enable automatic updates

ability to connect to external user databases (for OpenVPN roadwarrior access)

Features already introduced with 8.7.2 updates

Version 8.8.0 also includes some features that were already made progressively available through automatic updates of 8.7.2.

We report them here because they are part of the overall experience of the new version, but they may already be present on firewalls updated to 8.7.2.

Native integration with CLM

Native integration with CLM is included, making centralized management of appliances easier and improving alignment between the firewall and the connected management services.

Permanent OpenVPN connection logs

OpenVPN connection logs are permanent for all firewalls equipped with storage.

Storage is configured by default on all physical appliances, making it possible to keep a more reliable VPN connection history without requiring additional configuration in most installations.

Bug fixes

This beta includes several already verified fixes, including:

fixed the count of OpenVPN client tunnels in the dashboard, where disconnected tunnels could be shown as connected
fixed the status of users from an external database, who could appear disconnected even when they were actually connected
fixed restoration of extra packages after image update
fixed a Threat Shield DNS issue with empty lists after repeated changes
fixed issues related to disabled packages after updates
fixed a netifyd migration issue after image update
added additional logs when DPI blocks traffic

Why a beta?

NethSecurity 8.8.0 is not just a release with new features: it also introduces a major change to the system base.

The switch to the new platform version brings relevant updates to core components such as the kernel, VPN, package management, networking and security.

For this reason, we have chosen to publish a beta and collect feedback from the community before the stable release.

We are particularly interested in tests and reports on:

upgrade from previous versions
installations with additional packages
OpenVPN
IPsec
WireGuard
firewall and advanced rules
DPI
DHCP/DNS
Threat Shield DNS
Threat Shield IP and geoblocking
native metrics
alerts and notifications
configurations with external user database

Known bugs

The complete list of known bugs is available here.

Feedback

To report issues or share feedback on the beta, for maximum visibility we invite you to use this thread.

mark_nl · July 9, 2026, 5:56pm

Could you share the commit Beta2 is based on? (or even better tag it?)

Because the ns-storage package is stubborn in my effort to port Nethsecurity to arm64 I scrutinized this package. Now I take the opportunity to report issues that look odd to me.

As mentioned before the ns.ha has the same bug as found in ns-storgage. The call to get path to the dhcp-leasefile in get_dhcp_leasefile has one argument to much
(second " dhcp"):

github.com/NethServer/nethsecurity

packages/ns-api/files/ns.ha

b9634a2a9


      
          """
          
          def get_device_from_ip(uci, ipaddr):
              for n in utils.get_all_by_type(uci, 'network', 'interface'):
                  if uci.get('network', n, 'ipaddr', default=None) == ipaddr:
                      # Return a tuple with the (interface, device)
                      return (n, uci.get('network', n, 'device', default=None))
              return (None, None)
          
          def get_dhcp_leasefile(uci):
              return uci.get('dhcp', 'ns_dnsmasq', 'dhcp', 'leasefile', default='/tmp/dhcp.leases')
          
          def get_main_vrrp_interface(uci):
              for section in utils.get_all_by_type(uci, 'keepalived', 'ipaddress'):
                  if uci.get('keepalived', section, 'name', default=None) != 'lan_ha':
                      continue
          
                  ns_link = uci.get('keepalived', section, 'ns_link', default='')
                  if ns_link.startswith('network/'):
                      return ns_link.split('/', 1)[1]

This below does not determine whether the os_device is found; even if grep exits non zero as the mount point /boot is not found; piping that result through uniq and awk exits zero as long uniq and awk are found in the (subprocess) path.
Please note it would be very beneficiary for the arm port effort if Nethsecurity looks for the partition mounted on /rom instead of /boot to determine the block device on which re OS lives.

github.com/NethServer/nethsecurity

packages/ns-api/files/ns.storage

b9634a2a9


      
              except:
                  pass
          
              return {"devices": devices}
          
          
          def get_configuration():
              u = EUci()
              os_device = ''
              try:
                  proc = subprocess.run("mount | grep /boot | uniq | awk '{print $1}'", shell=True, check=True, capture_output=True, text=True)
                  os_device = proc.stdout.strip()[:-1]
              except:
                  return utils.generic_error("os_device_not_found")
          
              ret = {"name": None, "size": None, "path": None, "model": None, "vendor": None}
              try:
                  info = get_storage_info(u)
                  p = subprocess.run(["/usr/bin/lsblk", "--json", "-b", "--output-all"], check=True, capture_output=True, text=True)
                  data = json.loads(p.stdout)
                  cur = None

It is not possible to setup the permanent storage on a second nvme (or a SD-card) because their partition naming schemes are different form traditional block devices. The partition numbers have a p prefix. Here the offending line that assumes the newly created partition is called {device}1 on nvme’s, emmc 's and SD-cards it is {device}p1.

github.com/NethServer/nethsecurity

packages/ns-storage/files/ns-storage-setup-disk

b9634a2a9


      
          device=$1
          
          [ -z "$device" ] && eerror "Device '$device' not found"
          [ ! -e "/sys/class/block/$(basename "$device")" ] && eerror "Device '$device' is not a block device"
          mount | grep -q "$device" && eerror "Device '$device' is already mounted"
          
          # cleanup partitions
          dd if=/dev/zero of="$device" bs=512 count=1 conv=notrunc 2>/dev/null
          # create a single ext4 partition
          parted -s -a optimal "$device" mklabel gpt -- mkpart primary  1 -1 >/dev/null
          mkfs.ext4 -q -F -L ns_data "$device"1 >/dev/null
          echo '{"device": "'${device}1'"}'

Please note it would be very beneficiary for the arm port effort if Nethsecurity did not make assumptions on the partition naming scheme, possible like this:

While testing my solution for the partition naming scheme on X86_64 I removed and (re)created the permanent storage on different devices such as the nvme the OS lives on, a second nvme and a usb-drive.
Even though all is working well, I observed at some point the wrong partition was shown in the UI. I have not figured out why but have an strong hunch: If the permanent storage is removed the partition keeps the label ns_data. So while testing I ended up with 3 partitions labelled ns_data

root@NethSec:~# lsblk -o name,mountpoint,label,size,uuid
NAME          MOUNTPOINT LABEL         SIZE UUID
loop0         /overlay   rootfs_data 226.8M b6bcca32-4019-4154-94d8-2db91d6912b2
sda                                   59.5G
└─sda1                   ns_data      59.5G ecdc7c62-d821-4004-b458-cac8ed4002ce
nvme0n1                              465.8G
├─nvme0n1p1   /boot      kernel         16M 1234-ABCD
├─nvme0n1p2   /rom                     300M
├─nvme0n1p128                          239K
└─nvme0n1p3   /mnt/data  ns_data     465.4G 051b1224-5101-43df-8a56-9b25accd3c3a
nvme1n1                              931.5G
└─nvme1n1p1              ns_data     931.5G cd71df60-e662-4d25-b561-3baa735a07c7

Note nvme0n1p3 is mounted on /mnt/data not nvme1n1p1

jfranco · July 13, 2026, 12:54am

Hi and Thank you!

Is there a CLI manual with all the differences between commands from the old and the new?

I’m willing to put in production since this is my own network and I’m willing to risk.

Can I just upgrade to the beta version? It’s stated as a yes, but how about unlicensed servers?

About the external database usage in OpenVPN, will this be exclusevelly to VPN, or can we use for other services? On the same topic, what kind of database is this?

Thanks,

Tbaile · July 13, 2026, 7:32am

Slipped through my mind, addressed!

We’re looking into some ARM boxes to try, when I have something I’ll report back with additional fixes (or more support on the matter)

The only actual major change is that OpenWRT passed from opkg to apk, they have a cheat sheet on the matter, but reading anything apk related online would suffice.

The server is an Active Directory (or compatible), it’s used to have a shared userbase to allow access through VPN to. Allows centralized userbase, not much else, if you don’t use it, you’ll likely not need it

No difference for the unlicensed, make sure you run a backup before upgrading, if anything goes wrong restore a clean 8.7.2, update the packages, then restore the backup

m_farlotta · July 13, 2026, 5:52pm

Hello everyone, I wanted to try the NethSecurity 8.8.0 beta and wanted to update directly from NethSecurity, but the system gave me this message: “Invalid file format.”
I assume I need to reinstall it from scratch, or am I doing something wrong?
Thanks.

mark_nl · July 14, 2026, 4:10pm

Please note, this is a serious problem: all partitions that keep the ns_data label after creating/removing seem to be mounted on /mnt/data

From a fresh beta2 install on x86_64 with 2 nvne’s and one USB thump drive:

After creating and removing permanent storage the above drives and a reboot:

root@NethSec:~# lsblk -o name,mountpoint,label,size,uuid
NAME          MOUNTPOINT LABEL         SIZE UUID
loop0         /overlay   rootfs_data 226.6M 71d40bb9-b268-4fab-9845-0cc3b04f6849
sda                                   59.5G
└─sda1        /mnt/data  ns_data      59.5G 79f0da20-77b4-40d9-8994-cbec416d2ce4
nvme0n1                              465.8G
├─nvme0n1p1   /boot      kernel         16M 1234-ABCD
├─nvme0n1p2   /rom                     300M
├─nvme0n1p3   /mnt/data  ns_data     465.4G 010f4bdd-d3b4-4bad-8bd9-aa1859f9420e
└─nvme0n1p128                          239K
nvme1n1                              931.5G
└─nvme1n1p1   /mnt/data  ns_data     931.5G fb02ede5-de21-4bbc-8b4b-9811ebe4e45d

root@NethSec:~#  mount | grep /mnt/data
/dev/nvme0n1p3 on /mnt/data type ext4 (rw,relatime)
/dev/nvme1n1p1 on /mnt/data type ext4 (rw,relatime)
/dev/sda1 on /mnt/data type ext4 (rw,relatime)

mark_nl · July 14, 2026, 5:39pm

I do not experience this
EDIT
~~However my freshly installed 8.7.2 with all updates (first picture below) did not update to 8.8.0-beta2 and it did not throw any faults/errors at me.~~

image940×510 70.7 KB

Updating with uploading image nethsecurity-8.8.0-beta.2-x86-64-generic-squashfs-combined-efi.img.gz : @m_farlotta to my understanding one need to upload the uncompressed (gz) file

image940×332 66.8 KB

No failures/errors:

image940×322 57.3 KB

~~After a manual reboot it did not update 8.7.2:~~

EDIT : My own fault: bad download, some how I can not download it on windows with firefox. It did update with a good download

Tbaile · July 16, 2026, 9:43am

Something clearly happened in the background, not sure exactly what, are you able to run a backup? If it fails something in the system is keeping it from properly flashing. Probably something underneath got stuck during the update, not sure what.

If you can open an issue with your findings it’ll be awesome. Mounting script should get the first available drive and mount it, but it seems that underlying fstab implementation has other plans…

mark_nl · July 16, 2026, 11:29am

My bad: faulty download… It has updated now.

I will investigate further and open an issue

ismail_cetin · July 18, 2026, 2:27pm

Issue Summary: When attempting to set up the NethSpot (my.nethspot.com) integration via the NethSecurity Web UI, a “Request failed ns.dedalo login” error is encountered. The ns.dedalo login command suggested by the interface does not work directly on the CLI (command not found).

Analysis & Findings:

Package Status: The script exists at the /usr/libexec/rpcd/ns.dedalo path and acts as an rpcd plugin.
Network & NTP: The system time is up to date (date is synchronized) and the device has seamless internet connectivity to my.nethspot.com via ping (0% packet loss).
CLI (ubus) Test: When the login process is triggered directly via ubus on the terminal:

ubus call ns.dedalo login ‘{“username":"ismailctn@gmail.com”, “password”:“PASSWORD”}’

The command executes without syntax errors but returns a generic JSON response without further details:

{ “success”: false }

Request: Even though the credentials (username/password) are correct, why does the API return false and cause the UI wizard to lock up? How can we view the detailed background error logs, or how can this authentication mismatch be resolved?