NethSecurity Beta 1 is ready 🛡

Beta1 is here! :test_tube:

Our firewall has reached a new level of maturity as it enters the Beta1 version, with a lot of new features and enhancements for our vibrant community.

This beta release signals a significant shift to a new UI as the primary configuration interface, while still maintaining the versatility of Luci for specific configurations and verification purposes.

Key Highlights

New Configuration Interface

The new UI is now the primary configuration interface, streamlining the configuration experience. The old Luci interface remains active for configurations not yet available in the new UI and for verification purposes.

Certificate and Reverse Proxy Management

Navigate a dedicated page for easy management of certificates and reverse proxy settings. The import process for both configurations has been significantly improved. Now, you can also use DNS verification to request Let’s Encrypt certificates, supporting wildcard certificates.

Firewall Rules Configuration

Added a new page for configuring firewall rules, offering enhanced control. Users are encouraged to use this page for compatibility and optimal performance.

Quality of Service (QoS) Configuration

Tailor your network traffic management with a newly introduced QoS configuration page, ensuring a seamless online experience.

OpenVPN Roadwarrior Configuration

Dive into the convenience of a dedicated page for configuring OpenVPN Roadwarrior. The migration process for the new implementation has been diligently updated.

Other Changes in Beta1

  • Log Storage on Main Disk Partition
    Optimized storage resources by utilizing a partition of the main disk for logs, offering a flexible solution.

  • Migration and Compatibility Improvements
    Improved migration processes for multiwan and OpenVPN tunnels, enhancing overall system compatibility.

  • Upgrade and Migration Management
    Streamlined management experience for upgrades and migrations, ensuring a smoother transition for users.

  • Versioning System
    More clarity with our new versioning system, uniquely identifying each image to simplify tracking releases.

  • Usability Enhancements
    Benefit from numerous usability improvements and issue fixes across existing pages, providing a more user-friendly environment.

Try it!

Follow the instructions, download and try it
Download :arrow_down:


Read about all features, migration from NS7 and more inside the official documentation

We need your feedback

Known bugs in the new interface can be found here. Your input is invaluable in shaping the future of NethSecurity.
Explore the new interface confidently, but if you encounter bugs, please report them in a new thread.

Your feedback during this beta phase is crucial for refining NethSecurity.

Please open a new topic in the NethSecurity category
Add tags like feature bug support
We invite you to explore the Beta1 release, share your feedback, and be a part of the NethSecurity community. Thank you for your continued support and dedication to open-source excellence!

Happy exploring :artificial_satellite:!

The NethSecurity Team


thanks for this release, seems things are moving extremely fast over here.
2 questions av got.

  1. is ipv6 supported
    2 can this conect and or interface with ns8?
    to create a localhost bond, via internal vpn?


Sorry but I do not get this one.
Can you please explain your scenario?

Hello @giacomo ok, le tme expand on the use case and or scenario.

NEthsecurity is a firewall, and also includes a VPN integration.
it also kinda utilizes some components in Nethserver8 as well.

At the moment, NEthserver8 has an integrated VPN, which enables nodes to communicate and operate as if being on the same network(localhost)

While the nethserver instances are able to communicate to each other internall, they at the moment cant communicate externally.

Ofcourse a VPN module could be implemented to acheive this, but, what if this person is also using NEthsecurity in one of their sites.

the proposal is. Since we can already have VPN within NEthsecurity, and this can allow for a numbe rof scenarios, including connecting other not then systems and computers.

How about, MAking use of the same Node cluster engine thats being used with nethserver 8,
Implement a similar, Add Cluster admin Node into Nethsecurity, just by sharing the cluster admin key, similar to how nodes join.

When the NS8 node is joined to Nethsecurity, i can then apply the VPN to nethsecurity only, and all servers and clusters added, (with firewall rules) could be available as being within the same network.

So basically, Nethsecurity becomes the glue between other external systems into Nethserver 8.

IF i deploy Nethsecurity in HQ.
Deploy Nethserver 1 in branch 1
Deploy NEthserver 2 in branch 2
and deploy nethserver cloud in the cloud.

While the nethservers can communicate with one another on the same network band, and apps can talk to each other.

IF i have branch 4 with no nethserver8, i can have the user conenct via VPN through the firewall(NEthsecurity) and with that, they could be able to connect to the servers on the cluster, without going directly through the internet.

Hint for docs.

Since running from the USB stick does not guarantee best performances, you can also install NethSecurity to the hard disk while running it from the USB stick itself:

connect to the server using VGA, serial console or SSH

login with default credentials

Which are not detailed here…

Also: not even a console friendly wizard for network configuration? laaaaaaaaaame…

I get the idea. We are already implementing something similar, but not really the same.
Take a look at this: GitHub - NethServer/ns8-nethsecurity-controller

Still for now we didn’t think to make NethSecurity part of the NS8 cluster, but it’s something to explore.

You’re right, I just added a link, thanks for pointing it out!

Don’t “lame” yourself :wink: You can find it documented in many places if you search for OpenWrt, but this is the simplest one: [OpenWrt Wiki] OpenWrt as router device

Ok. Something got eaten. Dumb me.
Not considering 100mbps stuff as interface is a deliberate choice?
I mean…

03:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 03)
04:04.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8100/8101L/8139 PCI Fast Ethernet Adapter (rev 10)

Kernel seemd to have a gist of what it is, however eth0 is the gigabit one and there’s no eth1.

br-lan    Link encap:Ethernet  HWaddr 70:71:BC:08:1B:A6
          inet addr:  Bcast:  Mask:
          inet6 addr: fe80::7271:bcff:fe08:1ba6/64 Scope:Link
          RX packets:1562 errors:0 dropped:0 overruns:0 frame:0
          TX packets:2161 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:154510 (150.8 KiB)  TX bytes:2305628 (2.1 MiB)

eth0      Link encap:Ethernet  HWaddr 70:71:BC:08:1B:A6
          RX packets:1563 errors:0 dropped:0 overruns:0 frame:0
          TX packets:2161 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:176432 (172.2 KiB)  TX bytes:2305628 (2.1 MiB)

ifb-dns   Link encap:Ethernet  HWaddr DE:F8:7A:54:87:2F
          inet6 addr: fe80::dcf8:7aff:fe54:872f/64 Scope:Link
          UP BROADCAST RUNNING NOARP  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:32
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

lo        Link encap:Local Loopback
          inet addr:  Mask:
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:1060 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1060 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:122098 (119.2 KiB)  TX bytes:122098 (119.2 KiB)

This is not part of standard OpenWrt x86_64 build, I think it’s by design.
Still, I do not see any cons on including it in our build to support older hardware.

What do you think @filippo_carletti @davide_marini ?

This beta1 image is more focused on virtual systems, but we could offer a wider range of legacy ethernet drivers.

is this a nS8 module?

So how exatcly does this module not somehow try to implement what i was talking about above, seems to me like its what its trying to acheive.

NEthsecurity Does not form part of the cluster, quite to the contrary, because, NEthsecurity should have the capacity to join multiple DIFFERENT clusters.

the implementation logi is not that Nethsecurity joins a cluster similar to how ns nodes join one,

nethsecurity can join more than one cluster.

Now since its a firewall, and also has vpn, it would offer a kind of site to site vpn tunnel between the different clusters, as joined via the leader. from a local user, connected to the firewall VPN,

this would be Nifty, and a game changer.

It would offer a trully hybrid onprem and cloud network for organization infrastructure.

tailscale/headscale like kind of scenraio, but for apps and resources within NS8, with Nethsecurity as the bridge

1 Like

@filippo_carletti and @giacomo if 100mbps will be cut out I will be sad, disappointed, but think I could get why.

In Italy, slower connections are still under 100mbps (even asymmetrical) then older adapters are perfect for use (on bare metal) slower slots and slower hardware. It’s not power efficient, however it’s a way for not generate more eWaste. And sometimes, on VDSL connections… better to have the older card to take ESD.
For any othe use fast ethernet adapters are simply ready to be recycled, not re-used.

Hint for documentation.
In this page a link to OpenWRT packages/drivers for hardware

Could be useful?

Alot of industrial Equipments are actually running their controllers with 100 Mbps connectivity…

Older, yes. Current I don’t think so.
Gigabit ethernet is nowadays mature, reliable, cheap and efficient technology.
However, industrial equipment can be connected via switch; newer have some issues with 10mbps, however never miss a bit on 100mbps.

This should be a router.

ToH from OpenWRT reports the supported hardware, which is not the support for NethSpicAndSpan8 (consumer router on steroids), currently only x64 (no. 32 bit now for a perimetral device is a complete no go, there are too many unpatched vulnerabilities.)

Test comes a stop to me.
The system I used for testing had an issue considering a Realtek 8139 not an interface, however Realtek 8111 was fine (included into mainboard).
I had a 1gbe realtek card hanging around, slot was free, then plug it in. And i’m sure, kernel does understand the card is there.

However, i were not able to ping the device.
I setup the client from DHCP server to static IP. Can’t ping NethSec again.
Check cables and switch. Port off on the switch. Which is unmanaged, but the cable is connected. I plug the cable into the switch of the other card, 100mbps. Can’t ping NethSec.
Reboot NethSec, looking for the switch port. At power on, integrated adapter went 100MBPS. At some point into the boot process, the led turns off (aka “dead/unplugged” cable).
Shut down again, removed added gigabit card.
Powered on, switch led 100mbs. At a certain point into the boot process, switches to 1GBe. From client i can ping NethSec, and obtain IP address.

Faulty card? Well… Linux detects all cards nicely.

And uses correctly too: 1gbps for both RTL8111, 100MBps for RTL8139, ping and sustained data transfer. The OS is CentOS7 customized, NS7.

Trying to provide something useful: same driver adapter for multiple interfaces/zones has been tested?
Into virtual environment were used only the suggested/default drivers for all the guests?
Could be that the interface management engine do not handle that well omogenuos kind of chips or Realtek ones?
Is there a well known issue for OpenWRT on Realtek adapter?


If I recall correctly, a few months ago you posted an issue and solution for NS on a smaller, firewall type box concerning a Realtek NIC. Maybe it’s the same / similiar issue. Realtek does have quite a few issues as hardware, on several platforms / OSes…

Correct Detection does not mean a working card. I’ve had, in the past, plenty of hardware issues with cards that looked fine, and shown as working (In Windows and Linux). NIC even lit up when active ethernet plugged in, but never got it working. The card failed on 3 different hardware, so it got junked. Such cards are too expensive for me and my clients, even though it may initially have been free (lying around from another hardware…).

My 2 cents

This is the whole story, happened on a similar mother board. On CentOS7. Which has worked for more or less around three years on this hardware.
Now. This hardware works with CentOS 7. Tested.

And the behavior with NethSec is different, on the very same hardware, but with OpenWRT kernel.
Currently, due to this behavior, I’m not able to test NethSec. I don’t have any virtual hardware to allocate, I have currently no other hardware to use for this.

Sometimes life is unfair!

Wasted days trying to get a Mac Mini to run proxmox - after doing more than 10 similiar / same Mac Minis.

The only issue was an unusual Broadcom NIC for WLan (Proxmox, as I use it, never has WLan active!) which always crashed the installer.

After several days, i reinstalled MasOS on that box…
Sh*t happens!
Time wasted.

Maybe also learned not to waste more time in a box that costs almost nothing!


My 2 cents