Messages

Hi @allebone, Sorry for making you wait.

The challenge for us here is that netmap is part of the Operating System and is developed and maintained by its own team. Since it's not part of zenarmor codebase, we reach out to the authors and sponsor this kind of development.

This generally takes longer than shipping a zenarmor functionality.

Having said that, the "current plans" are that we'll be sponsoring another round of work, sometime during this year.

I hope this answer is more helpful to you. 

Hi @allebone,

Yes, the problem with wireguard kmod is that it does not have netmap support. For now, the best option would be wireguard go if you want to monitor the wireguard interface with zenarmor.

Having said that, we want to help wireguard kmod have netmap support and for that we're looking into several alternatives to make that happen.

Dear zenarmor users,

We've shipped zenarmor 1.11.4-rc1 on the OPNsense 22.7 branch.

This release is meant for compatibility with the upcoming OPNsense 22.7 release.

Please feel free to report any issues you've encountered and we'll get them all sorted out before OPNsense 22.7.

Hi @FullyBorked,

Thanks for the suggestion. We'll make this stuff a bit smarter ;)

Hi @athurdent,

One of the reasons why we ideally want to have a single code base for both the OPNsense UI and Cloud is that this will significantly reduce our time to ship new features.

Mobile-friendly UI is on the roadmap. Once it's there, it'll work for both of the interfaces.

Hi @walkerx,

Yes, this is not directly related to Zenarmor. It's because of netmap(4); an Operating System subsystem we use to grab packets off the wire.

If you have IPv6 WAN tracking enabled in a netmap enabled interface and when an application opens the interface in netmap mode, netmap re-initializes the interface; causing the interface to go DOWN/UP. Since you have WAN tracking here, this in turn triggers the OPNsense code to re-configure the related WAN addresses. This whole process can take up to a minute, during which time you lose WAN connectivity.

The behavior is the same if you use Suricata in IPS mode, which utilizes netmap the same way we do.

Having said that, we are evaluating several options which would potentially solve these sort of issues and would add device-independent IPS capabilities. If we can work out a methodology at least in theory, we'll go ahead and sponsor a development on the Operating System side of things.

Stay tuned for more updates on that.

I hope this is helpful.

Dear beloved OPNsense users,

Your opinion matters to us. Please help us decide the future of Zenarmor's UI on OPNsense

In the past year, Zenarmor's Cloud User Interface received significant improvements on the usability side. We want to bring those improvements to the Zenarmor OPNsense plug-in.

We have two options that we would like you to see and provide your feedback.

Please have a look at the Poll below and share your opinion with us.

https://docs.google.com/forms/d/1pWbiObQsKgdaUIduI_mImLo-MW695KmfftwxizxVBzc/viewform?ts=62a4f641

Best
Zenarmor Team

Hi @spetrillo,

That work was meant to tackle the most pressing issues on the netmap side. The developments have already been incorporated into the OPNsense source. So it's all there.

Having said that, there are still some other areas that need to be addressed. lagg(4) is one of them.

To our experience, almost all major netmap related problems stem from driver incompatibilities. The underlying reason is that netmap mangles heavily with device drivers to be able to make maximum use of their capabilities and speed.

This totally makes sense from a performance perspective; however comes with the penalty that it is very hard to maintain.

We're tinkering around with an idea of a netmap emulated driver which will behave like a BPF interface and will support inline operations.

This is currently in the idea phase. We'll update the community once we have something more concrete.

Hi @Nambis,

Yes, along with Device Identification, it's currently the #1 item in our agenda.

2.0 will bring landing pages for TLS blocks: Zenarmor will display a landing page for TLS-enabled connections.

We're looking to see if we can also include the Full TLS Inspection capability in the same release. Having said that, chances are high that it'll be shipped with 2.1.

As a timeline, you can expect it to land in Q3 if all goes well, and nothing extra ordinary comes up.

Hi @firewall,

Thanks for the follow-up. We've discussed this with the team and decided that the best way to go would be to provide our users with a "Privacy Check Tool". 

This way, any updates on the software could also be reflected through the Privacy Check Tool in parallel and without any delay.

This is already in the making and planned to ship with the next major release.

Please see the attached picture (from our Project Mgmt Tool) for the details.

@lrosenman, team is on it. Looks like a nasty one to debug. Team will update you through the help system.

Hi Steve,

Can you take a look at this doc:

https://www.sunnyvalley.io/docs/opnsense/configuring/reporting-data#directory-storing-database-filespath-for-elasticsearch-or-mongodb

Hope this answers your question.

Hi @k0ns0l3

Checked this with the team. /dev/md98 is not related to Zenarmor.

Maybe some other plugin is creating that?

Anyhow feel free to reach out to the support. Team will be happy to have a look.

Hi @k0ns0l3

/dev/md98 did not seem familiar to me. Zenarmor's memdisk device is  /dev/md43.

Let me check with the team again.

Other than that, zenarmor's memdisk should not survive reboots unless you have the Zenarmor Packet Engine is set to be enabled at boot time. Memdisk is created by the rc service script.

@lrosenman thanks.

@k0ns0l3 run below command on the console, that should unmount the file system.

Code Select Expand

/sbin/umount /dev/md43