Messages

Hi @johndchch,

We intentionally pin zenarmor to a dedicated core in order to prevent CPU context-switching overhead. Because if the process is wandering around CPU cores, we start to see CPU cache misses, which will in turn negatively impact performance.

Having said that, it's very interesting that you're seeing the opposite. Can you provide a bit more information? What is the CPU model? Is there a specific server hardware you're using?

Hi @greY,

What happens if you put zenarmor into Bypass Mode? Is it the same?

Hi @tuatara,

Thanks for your interest in a zenarmor paid subscription. Please find below information about how we process refunds:

For Monthly Subscriptions:
* Cancellation requests can be made anytime. Subscription is terminated at the end of current term. No refunds.

For Annual Subscriptions:
  * If the cancellation request is made within the same month the subscription is started, subscription can be terminated immediately and 100% of the subscription amount minus any applicable fees will be refunded. Otherwise, no refunds.

We see that if people want to experiment a little more, they start with a monthly subscription; and once they're more comfortable with the software, they upgrade to an annual subscription.

Hope you'll find this information helpful. 

PS: We could not locate any recent questions about licensing in our support system.  Any chances you can share your ticket/email information with me with a PM? Let me try to see why we could not get back to you promptly.

Hi @jkemp,

Got it. This means the firewall itself does not use the VPN route.

It's a bit tricky and also very hard to provide guidance without having a look at the whole configuration.

But in a nutshell, you'd want to route everything (0.0.0.0/0) through the VPN gateway, with the exception of the VPN server. The communications to the VPN server should use the existing ISP route; since otherwise you'd lose VPN connection.

Got it, thanks. Any chance you run a traceroute to 1.1.1.1 from the firewall console? Does that use the expected route?

Hi @jkemp,

Cloud queries should be routed through according to the FW's routing table. Zenarmor does not modify routing entries.

Maybe the VPN route is not in effect for FW originated connections?

Hi @Taunt9930,

My pleasure.

Zenarmor utilizes 6 different mechanisms (ranging from MDNS/SSDP/LLMR to static IP mappings). These have confidence levels assigned; so for instance, if zenarmor detects a reverse ip mapping for an IP address, which has a higher confidence level than an LLMR message, it'll start to use that resolution for the same IP address. This is why you might be seeing different types of hostnames. For now, the mappings are not persisted to a database though.

2.0 will ship with Device Identification, which will have the necessary pieces to provide more streamlined user experience.

On the other hand, for now, if you have static mappings for IP addresses, you should be able to see them resolved in the charts/reports. Let's have a look at this to see if we're missing anything.

Hi @Taunt9930,

Need a bit more information here. Do you see some hostnames resolved or nothing at all? And if you're seeing some hostnames, are the missing ones IPv6 addresses?

Hi @Vilmalith,

No. Zenarmor runs fully transparent and (apart from Suricata in IPS mode protecting the same interface) runs fine together with other applications on the firewall.

You should be fine using any DNS-based solution together with Zenarmor.

Hi @sghost,

Thanks for sharing your thoughts. Much appreciated. Your point is well taken and we completely share your point of view.

Taking the chance I want to share Sunny Valley Networks' official stance on Privacy and provide an update on what we've been doing in this regard.

We've spent almost a year on both the technical and regulation (GDPR, California Consumer Privacy etc.) side of things to align industry best practices and our users' expectations with our infrastructure.

Reading our beloved users' feedback afterwards, it became apparent that we also needed to provide "detailed technical information" on what data we're collecting; for what purposes and how our users can manage zenarmor settings to control their data sharing status.

The first idea was adding these information to legal documents; but managing technical detail in legal documents appeared to be more challenging than we originally thought.

After doing an extensive research for industry best practices; It looks like the best method will be providing our users with a dedicated 'Privacy Settings Menu' where we can disclose which information you're sharing, the reasoning behind this and a quick on/off button to disable/enable related functionality so that you can easily control your Privacy posture.

This functionality will ship with the upcoming Zenarmor release 1.12. I'm attaching the screenshot of the aforementioned Privacy menu. 

It's a cliche; but I'll have to say it anyhow just to express our stance: your privacy is utmost important to us. The product has been designed, from ground-zero, keeping this in mind. OPNsense user community is highly privacy-conscious. Working with such a community helped very much as well.

I guess we're the only product offering a Cloud Management capability and at the same time offering the option to store reporting data locally on the user's premises. We store only what is necessary to store in the Cloud. All cloud communications can be monitored through zenarmor agent's cloud agent logs. You'll notice that apart from the connection keep-alives; there'll be no messages going back / forth unless you're signed-on to the Cloud Interface and interacting with the related menus.  From a product development perspective, this kind of approach brings with it a lot of challenges. However, we believe this is the right approach.

Our intent is to provide a privacy-safe and secure environment to our users. If the 'practice' does not align with this 'intent', please be noted that it is unintentional and we're all open to constructive suggestions like the ones in this thread and more than eager to revise our processes, products and services.

In that regard, we've already reached out to several forum users who shared their suggestions. Some of them were kind enough to contribute further ideas which eventually helped create our current approach.

Apart from that, I'd like to also re-iterate that we're open to helping people who might want to conduct an independent analysis of the privacy situation of the product. Please feel free to reach out to privacy - at - sunnyvalley.io . Your suggestions and ideas are always welcome.

Thank you

@opnsenseuser, got it. Totally makes sense. We'll be looking into this.

Yes, block notification page is fully customizable.

Hi @opnsenseuser,

Thanks for the feature suggestion. We've received this from a couple of users. Let's see if we can find a sustainable way to do this.

Hi @opnsenseuser,

Yes, this is already possible with HTTP (clear-text).

For TLS-encrypted connections: we're currently working on this. (See attachment).

It'll ship with 1.12 if all goes well.

Thanks @franco, very much helpful. I'll be reaching out to you about this.