Messages

Hello.

I am a licensed user of the 26.4 Business edition.

I am busy researching what all of the various OpenVPN Options and Push Options that OPNsense support do..., but I'd also like the forum's opinion on which set of Options and Push Options that you would recommend for a typical Road Warrior configuration to connect into a lab network?  (This is not a home lab.  This is a real, business lab environment.)

My initial thoughts are these:

Options:
--------
block-ipv6

Push Options:
-------------
push block-ipv6 (do I need this in both spots?)
push block-outside-dns
explicit-exit-notify (since I am using UDP)

I'm looking for your opinions on best practices for these settings, I guess.

Also, what is the differences between Push Option "push register-dns" and the stand alone setting "Register DNS?"

Thank you.

Greetings.

I am a licensed user of the 26.4 Business edition.

How do Privileges work for a User that is a member of multiple Groups - each with a different set of Privileges?

For example, suppose a User, FOOBAR, is in the "admins" Group with "All pages" Privileges and also a member of the "RemoteAccessVPN" Group that has no Privileges at all.  (Btw, I have NOT configured any Privileges at all in FOOBAR's User settings.  It is my understanding that one should use Group Privileges instead?)

1) What is their effective set of Privileges?  What determines those?

The end goal I'm trying to achieve is that when FOOBAR is connected to the RemoteAccess VPN, they have no Privileges, but when they are physically connected to the LAN network, the have full privileges.

I thought I might be able to achieve this by specifying "Enforce local group" on the RemoteAccess VPN (OpenVPN), but I'm also using external authentication (Active Directory) to do the authentication, so my understanding is that "Enforce local group" cannot be used in this scenario.

2) Should I use two different User accounts to achieve this?  FOOBAR-Admin with "All pages" Privileges and FOOBAR-VPN with no Privileges?

I'd appreciate it if someone could help answer questions 1) and 2).

Thank you.

Greetings fellow OPNsense enthusiasts!

I regularly use (daily, in fact) the testmynids.org script from 3CORESec to validate that my IDS/IPS detection and alerting pipeline (using OPNsense and Graylog) are working correctly.

Starting around 27 March 2024, the "Bad Certificate Authorities" (Option 4) started failing to be detected.

1) Does anyone else use testmynids to verify the proper configuration and operations of the IDS/IPS on their OPNsense?

2) Does anyone know if this is this a known issue with current Suricata rules?

3) Can anyone else replicate my experience (i.e., the non-detection of the bad certificate authorities) with their setup?

NOTE: I have had intermittent failures in the past where some of the testmynids tests failed for a day or two, but those seemed to fixed in short order after a new IDS/IPS signature download.  Nothing that's lasted this long - nearly two months!

[--redirect-gateway def1]

Hi, benyamin.

Thank you for your response.

No, the configuration doesn't use --redirect-gateway def1 or similar.

I'm not being pushed anything like that either.  (I control both ends of the OpenVPN tunnel, and nothing has changed on the server side.)

Don't pull routes and Don't add/remove routes are both unchecked.

Can you tell me more about

OpenVPN gateway behaviour has changed, but if anything, it is arguable that it is now working as intended.

?

I've got the firewall configured as an OpenVPN *client* to connect to an OpenVPN server that I can then selectively route traffic outbound through the firewall to.

This is working great on my 22.7.11_1 firewall.

But on the firewall that I upgraded to 23.1.7_3, the OpenVPN client doesn't seem to be getting a gateway address from the OpenVPN server like it should (and like my other one does).

I didn't see anything obviously related in the OpenVPN log files...

Any ideas?

I'm wondering if anything more came from this?  I'm seeing the same errors in my Suricata logs.

Just wanted to tag on to this.  I'm having the same problem: "KDF_PRF with PRF_UNDEFINED not supported" with my IPsec configuration.

The strongwan-kdf.pkg fixed it for me also.

Current set up:
o IDS/IPS (Suricata) is configured with "Enable eve syslog output."
o The firewall is configured to send syslog to a remote syslog server.
o The syslog server (Graylog in our case) is configured to email the admins when certain alerts meet certain conditions.

What I want to do:
o Setup up a cron job on a machine behind the firewall that occasionally does _something_ that triggers a Suricata alert that Graylog can match on to satisfy a "proof of life" condition.  If that condition is not met, Graylog can send an email to alert the admins that they may not be receiving IDS/IPS alerts like they are expecting.  (And/or have Graylog email the admins occasionally saying the condition is being met.)

So... is there a standard, innocuous event I can trigger that would cause Suricata to alert?  I was thinking something like trying to download EICAR or something.  (If I go with EICAR, what ET list would that event be in?  Malware?)

I'm open to feedback on further improving the whole system too if people have thoughts.  Thanks.

Anyone have any thoughts on this?

Specifically, what OpenVPN options does OPNsense's "No Preference" translate to?

Is there a way I can turn on debugging or look at log files or something to figure this out?

Thanks.

JD17

Can someone verify my understanding, please?  (I'm trying to implement mitigations against VORACLE attack.)

Setting "Compression" to "No Preference" actually *disables* compression in OpenVPN, correct?  I.e., it omits both the legacy "comp-lzo" and the newer-but-still-not-recommended "compress" options, right?

I wish the terminology used for this setting was a bit clearer, but apparently this is a complaint I should take up with OpenVPN not OPNsense  ;) as it seems to be their definition.

JD17

This post deserves a thousand "likes!"

I just upgraded from 21.1.x and ran into this issue.  Thank you so much for the solution!

It does seem like something the upgrade process ought to 1) fix or 2) not introduce - it's unclear to me where exactly the issue lies.

JD17

Perhaps this has been resolved too...?  I did get an updated set of rules on Monday - finally.

Well... the heartbeats work as I reported a few days ago, but the ET Pro Telemetry rules have *NOT* been updated since September 18th.

Neither the "Services > Intrusion Detection > Log File" nor the "System > Log Files > General" indicate there is any error downloading new rules.  Frankly it just looks like they haven't updated them for a few days.

Is Proofpoint still supporting the "ET Pro Telemetry" edition rules?

Thanks.

JD17

Edit: Added the missing word "*NOT*" in the first sentence.  It was kind of important, lol.

Yes, the issues seem to be resolved for me - at least, the heartbeats are going through now apparently.  Not sure how often the ET Pro Telemetry edition rules themselves are revved from Proofpoint's side, but the last set of rules the firewall downloaded were going on 16 hours old when I just checked (I have the firewall configured to download fresh rule sets every 6 hours).

Thanks for the help!

Thanks, Franco and OPNsense team for passing this on to Proofpoint.

Like @joeyboon said, the "connection error sending heartbeat to https://opnsense.emergingthreats.net/api/v1/telemetry" issue appears to be back.

Edit:  Anxious to hear about a resolution.

JD17