Messages

Same issue here with GoDaddy ... discovered today that they modified their API in deed...

I will definitively spend some time on figuring out a plan to get rid of them and move to a proper name registrar service.

In the meantime, I am using certbot in manual mode to manually generate my certificates using the DNS challenge : https://eff-certbot.readthedocs.io/en/latest/using.html#manual @ThyOnlySandman

Thank you for your suggestion, you are most likely correct.

However this does not address the main reason for my post: it seems policies are not working as expected, or I am doing something wrong.

I picked those rulesets mostly as examples to illustrate the issue and the way I was configuring it in case there's something wrong with the way I did it.

So I am still wondering if there is something going on with Policy management in OPNsense Intrusion Prevention?

Hello,

Running OPNSense 23.1.1_2 with Suricata enabled as IPS.

I wanted to update which rules are enabled and drop/alert and decided to cleanup all my policies, rule adjustments and enabled rulesets and start back from scratch.

I then enabled the following rulesets:

• abuse.ch/Feodo Tracker
• abuse.ch/SSL Fingerprint Blacklist
• abuse.ch/SSL IP Blacklist
• abuse.ch/ThreatFox
• abuse.ch/URLhaus
• ET open/drop
• ET open/dshield
• ET open/emerging-malware
• ET open/emerging-mobile_malware

I then went and created a first policy that I called "Disable all" which, as its name indicates, disables all rules ("Nothing Selected" everywhere and New Action = Disable).
I enabled it and applied and then went to check that all rules were in deed disabled.

Then I disabled that "Disable all" rule and created a new one called "Specific Ruleset all rules drop".
In the "Specific Ruleset all rules drop" I selected the following rulesets:

• abuse.ch/Feodo Tracker
• abuse.ch/SSL Fingerprint Blacklist
• abuse.ch/SSL IP Blacklist
• abuse.ch/ThreatFox
• abuse.ch/URLhaus
• ET open/drop
• ET open/dshield

Left all the other selection fields to "Nothing selected" and set New Action to "Drop". My goal being to go and enable all the rules for those selected rulesets and set the action to drop.

I made sure that policy "Specific Rulesets all rules drop" was the only one enabled and clicked "Apply"
But then, when I go and check the rule list, the first thing I observe is that a lot of rules are enabled, but on alert (instead of drop).
Also I can see some (but not all) of the rules from the rulesets I did not select (ET open/emerging-malware and ET open/emerging-mobile_malware) are enabled and set to alert as well, when they should have remained disabled.

I initially created both policies with priority 0 (and as described above, I was making sure I only enable one at a time when I click "apply"), and then I tried them again by assigning different priorities to them (and still making sure only one is enable when I hit "apply"), but that did not make a difference.


I did not remember running in this problem back in OPNsense 22.x

Am I doing something wrong here? or could something have changed in OPNsense 23.x ?

Hello,

I am using Monit to check on various things, including the VPN connections to my system.
The script I use to check the VPN connection outputs the list of connections and all that get sent to me via email when changes occurs (so I know if something unexpected happens on the VPN side).
However, I noticed that the output I receive in the email is truncated.
Also, checking the monit status (both in the web interface of OPNsense and command line) , the output is trunctated as well.

I found out the reason: monit has a default limit of 512b for program outputs.
This limit can be changed (https://mmonit.com/monit/documentation/monit.html#LIMITS). However if I go and change it in the monitrc config file, it will get overwritten by OPNsense next time.

What is the proper way to set those monit LIMITS with OPNsense ? Is there a way to add a custom monit config file that can get appended or prepended to the generated monitrc ?

Thank you

@franco

Just wanted to report that ever since I applied this patch, the issue did not happen anymore.

So I believe you are correct, it is related to https://github.com/opnsense/core/issues/5646

Thank you !

I applied the patch and will let you know if the issue still occurs.

Hello,

Since OPNsense 22.1.3 or 22.1.4 (I updated directly from 22.1.2 to 22.1.4), I have a strange behavior regarding CARP failover and my WAN interface DHCP renewal.

My OPNSense HA setup consist in 2 OPNsense instances on 2 different systems which are both connected to the same router for their WAN interface.
The router assigns each OPNsense an IP via DHCP and renews it every 24 hours (the DHCP configs is "static" in the sense that the MAC address of each OPNsense is assigned an IP in the DHCP server of the router - but from OPNSense point of view, it's DHCP served).

This has been working like that for years and no issues.

But lately (after the update from 22.1.2 to 22.1.4), every time the WAN DHCP address renews on my primary node, CARP would failover the WAN VIP to the secondary node (and just the WAN VIP, the other VIPs for my other VLANs all stay on the primary) and it stays like that, it never fails back to the primary.

While in that state (WAN VIP on secondary and all other VIPS on primary), several things are not working properly including some VPN connections I have and overall I notice some weird/slow DNS resolution and other slowness.

The only way I found to put back the WAN VIP on the primary is to go on both the primary and secondary, disable carp and re-enable it (sometimes I need to set carp persistent mode on secondary to force it back to primary).

Before 22.1.3, I never observed this behavior (and if it happened, it was probably very short and failed back right away so I never noticed it ?)

I noticed in the release notes of 22.1.3 the follow changes:
- interfaces: do not update VIPs on dynamic address changes
- interfaces: remove unused reference and return value from interface_carp_configure()
- dhcp: stream-read log and leases files for "dhcpd update prefixes" action
- ports: dpinger 3.2 [3]

Could any of those changes be related to the behavior I am seeing ?

Thank you.

@mb,

Thank you for your reply and I am happy to hear that you plan to get better documentation regarding the data that's being shared/collected.
I look forward to see and check it.

I also hope for "better" (or more) control over the shared/collected data.

If you are interested in ways to better explain and let the end user control how the data is shared and collected, I would gladly share my ideas.

The privacy policies here  https://www.sunnyvalley.io/legal/privacy-policy do give some information, but not enough details to build the trust that I would think a lot of users are looking for.

A lot of people implementing such solution (including me) are usually looking for both security and privacy (data security/privacy). Ideally, once such solution is implemented, it would not "leak" any kind of data at all.
While this is very difficult (but not impossible), I can understand that some data has to be shared for certain features.
In that case, I would like to have details and information about the exact type of data that is being shared, for how long and what controls I have over it.

It seems that some pieces are here (some in privacy policy, some in the doc), but it is not clearly spelled out and it feels like some features that "may" be sharing data are not identified as such.

We learn from sy that 2 features that send data out there can be disabled in configuration.

After disabling the Cloud Portal, Zenarmor queries web traffic for Threat intel and sends the heartbeat. You can configure both on Configuration - Cloud threat Intel and Configuration - Updates & Health.

While the configuration for Cloud Threat Intel was indicated in the documentation, I did not know that the heartbeat was actually also sending data out to Sunny Valley.
It would help building trust if it was clearly spelled out that those 2 features are sending data out (and what data exactly) and that you can disable them if you do not want your data to be shared (directly in the web ui - there's this little "i" icon to put descriptions and details for the different options/parameters).
It also makes me wonder if there could be other features/parts of zenarmor that may also be sharing data without my awareness ?

At the end of the day, once data has been shared, it is out of your control (unless you're being granted some control over that shared data) and trust is the only thing left.
For me, it requires more transparency and details to get that trust. It may also require giving more control over the shared data to the owner of said data.

So in the current state, there is not enough details, transparency and controls for me to trust and be comfortable enough to use zenarmor.

As said before, I have been considering purchasing a subscription (which requires sharing more information), because zenarmor does a good job at integration (with OPNSense), and detecting and blocking threats. But It lacks on the data privacy and controls side.

I do hope though that things will evolve on that side (more details and transparency in both documentation and product about what is shared and more control over what is shared) so that I can build that trust.

Hello,

I would also be interested in understanding the data that Zenarmor shares with Sunny Valley server/services and other third party.

I have been using the free version in passive mode, and I would consider purchasing a license and use it in active mode. However, I would like a clear understanding of what data is shared, how often, why and how it is affected by the different options available in the configuration.

After all, I consider Zenarmor as a shield against not only malware and other cyber threats but also against the data collection done by so many companies and actors online. So if Zenarmor itself does some data collection/sharing, transparency about what data is shared as well some control over it seems pretty important.

@mb, I notice links to "View Privacy Policy" on most configuration page, but neither the privacy policy page or the documentation details the data collected by zenarmor and how to control it. (for example, when "Cloud Threat Intel" is enabled, does zenarmor shares any of my data with Sunny Valley or other third party ?, or when enabling "health check" ?). Would it be possible to get more information about that ? Thanks.

Hello,

With the recent change in the way 21.7 handles the RSA certificate by using the new identity parsing with the ":" (https://wiki.strongswan.org/projects/strongswan/wiki/IdentityParsing)  I ran into some issues.

I have another strongswan instance running on a Linux server (not OPNSense), and on that remote instance, I have strongswan configured to use certificate in p12 format (which is supported as indicated here: https://wiki.strongswan.org/projects/strongswan/wiki/P12Secret

However, strongswan is a bit difficult on how the leftid / rightid need to be filled in order for it to properly find the private key in the p12 certificate.
I found out that the best way to find out the private key in the p12 certificate to use is to use the asn1dn for rightid/leftid.

However, to use it properly, double quotes need to be put in place, and if they are not put exactly like strongswan expects it .. then it wont find the private key to use in the p12 certificate.

For it to find it, the proper syntax is to have the whole "asn1dn:#307e310b30..."  in between double quotes.
So this does not work : asn1dn:"#307e310b30..."

And unfortunately, in version 21.7, it automatically writes the asn1dn:  for us when we select it in the dropdown with no possibility to add the double quotes before.
In previous version (21.1 and before) it did not add the asn1dn:    so it was easy to just go and put in the input field the whole "asn1dn:#307e310b30..."   and that would work.
But now, putting the whole "asn1dn:#307e310b30..."   in the field results in  asn1dn"asn1dn:#307e310b30..."   in the configuration file which is not working of course.
So all this results in the IPSEC on OPNSense never finding a proper match (because of the way it generates the input in the config)

So my request would be to add in the dropdown a "raw" or "custom" option which just let the user input exactly what he wants and not generate anything around it. That would solve a lot of those issues.

So far, the only way I got it to work on 21.7 is to go and manually edit the ipsec.conf file to put in the way it expects it, but of course this is not viable as it will get overwritten.

So again, just adding in the dropdown an option for the end user to put in exactly what they want and it gets in the config file as-is without any modification or massaging.

Thank you !

It is at the Remote Elasticsearch. In local elasticsearch, it is normal. We are working on it.

So, I believe you fixed it in latest version 1.8 as now I can see over 10,000 connections in my dashboard and report (had 68K connection on my report last night and 34K on dashboard right now). Thanks !

However, the Top Local Hosts and Top Remote Hosts still do not make sense, both contains local and remote hosts where I would expect the local hosts would only contain IPs belonging to my local network/subnets and remote host should only contains IPs that do not belong to my local subnets.

Using Elasticsearch v 7.10.1 for the database, and it's a standalone database, not part of sensei.



I also want to indicate that I am using Sensei in passive mode.

Hi Fright, sorry I only saw your answer now.

I did not get to test it, but I migrated to 21.1 which seems to contains the patch ?

I do see for example that there are no more entries with nothing, instead they all have 0  which is good.

I did try to sort on a given column, and I thought it did not work at first, but then I realized, it works per page only.
So if you want to sort on the whole list, you need to select "all" in the dropdown to indicate how many entries per page.

It is fine for my usecase as my list only has 3000 entries (so far), but I imagine that for bigger list, the page may get slow and take time to display/refresh.

Do you think it would be possible to implement a sort on the full list even though it displays only a few entries per page (25 for example) ?

In any case, thank you for this !

I updated last week end to OPNsense 21.1 and Sensei 1.7 and I still see the same behavior:
- always 10,000 connections reported in the quick facts
- remote and local hosts still mixed up

So the update did not "fix" those.