Messages

Oh, maybe the state type of NONE is the switch  to turn it off.

good day

Hello viragomann,

Thank you for your ideas.

I tried adding a sloppy-state rule to allow the packets, but to no avail. I would believe the sloppy-sate still checks the state table, even though without checking the sequence#, as per the online help.

Finally I fixed the problem by adding a static route to make the return packets get routed back to the OPNsense box that handles the inbound packets and mains the original entry in the state table.

I believe that dropping returned packets due to the asymmetric routing is a builtin security feature like many other firewalls do. I am wondering how much would it hurt if OPNsense team could add a switch to turn it off in some particular scenarios?

thanks to all who gave some hints, and to the viewer as well.

@chemlud, what is the word 'föck'?  ;D

@Patrick,

I agree with you about the symmetric routing being sub-optimal. Anyhow, the bad thing will have remain in place for a while, unfortunately.

However, I did a test where the OPNsense did not block the returned the packets even though these packets were received from another Interface than. the difference in this test scenario was that the OPNsense has the flow in the state table.

So may I draw a conclusion that the OPNsense does not simply block/cut the traffic because of the asymmetric routing, but check the state table first. If there is a state entry having the tuple of src and dst, port... the OPNsense would pass them even though the returned traffic comes in from another interface.

I am guessing.

Again, anyone can answer my second questio (is there a way to circumvent the "asymmetric cut")?

thanks

Asymmetric routing bad. Fix your routing.  ;)

The state that goes into the state table for allowed connections/flows explicitly contains the interface. If a service can be reached via two interfaces in two different networks/VLANs/whatever - why go through the firewall in the first place?

thank you for your reply. really appreciate it, but my questions were not answered.

1. is the feature of antispoof of OPNsense blocked those packets?
2. is there a way to circumvent it for a specific rule?

Don't get me wrong Patrick, get my sincere thanks to your reply.

Hello,

I created this topic after I did a some search on the topic of antispoof, but failed.

Here is the issue.

Problem:  The default deny drops packets that should be allowed by an explicit rule (src, dst, int, direction in...).

Bear in mind though, these dropped packets have the source IP on same subnet as of Int A,  and are received from int B. Is this because of the anti spoof in OPNsense? if this this is the case, is there a way to disable the anti spoof for this specific rule to allow these packets? (for whatever the reason, we need this asymmetric routing.)

Thanks

Thank you for your quick reply.

But that is not my question. My question was not about the severity of this vul., nor the plan of OPenSSL.org, but about the OPNsense's plan to patch it.

Anyhow, your reply is highly appreciated.

Any answers about the OPnsense patching plan would be appreciated.

O.K., sorry to break this to you in more clarity:

Though I cannot speak for the OpnSense developers, my educated guess is that there are no plans to patch this at all in OpnSense before new upstream releases become available. OpnSense is a FreeBSD derivative, which in turn uses OpenSSL - the originator of the ("vulnerable") software, thus it is two levels downstream from the origin of the problem.

As I already showed you, OpenSSL themselves have no plans to patch this now. This means that is highly unlikely that the FreeBSD folks will patch it before the next regular OpenSSL release. Which in turn means I cannot imagine that OpnSense will patch it in face of no neccessity to do so.

That is just the way how stacked dependencies work in Open Source (tm). If you do not believe me, you can try to do a "vulnerability" scan of a fully up-to-date Ubuntu 22.04 LTS server with the likes of Wazuh or similar. You will find more than 100 current unpatched vulnerabilities, many of which are from Debian (upstream of Ubuntu) with a status of "wontfix" - just because the upstream package developers have no fix either.

Some people seem to not understand this and have the childish wish to fix any "vulnerability" that shows up in whatever context. Won't happen. I even know of regulations which demand companies to actively look and fix such vulnerabilities. Then people ask Open Source developers to fix problems at once, which often is only possible by using the next big thing (i.e. next release) of some upstream package. Alas, their developers often do not provide a backport fix because they have done a whole new release already, which in turn cannot be used because of new "features", aka incompatibilities which would have wide-ranging consequences along with the security fix.

OpenSSL is one good example for this. Matter-of-fact it is not long ago that FreeBSD switched from OpenSSL 1.0 to 1.1 because of incompatible features.

For these reasons, there are few exceptions to the rule "if upstream does not fix it, we won't, either". Probably with CVSS scores > 8, but only if the scenario allows exploitation, none of which is the case here.

Thank you for your elaboration on this. You have nothing to be sorry about, my friend. Your reply is appreciated. I fully agree with you that open source providers/developers would usually not take action on the vulnerabilities lying in the upstream stuff, which is the default strategy. I was just curious if they have any plan. If not, some customers may think about switching to other options since some of them may have a very strict security policy in place, reasonable or not.

Again, Thank you guys. You replies are all informative and helpful.

Any answers about the OPnsense patching plan would be appreciated.

You appear to have received your answer already. Any particular reason you believe that Opnsense's strategy should diverge from that of OpenSSL in this instance?

Hi,

Sorry I have no reason at all to believe they would switch or not. OPNsense team has the discretion about the choice off xxxxxSSL. This is why I was asking even though I know mostly and ususally they would not. As per my limited experience on the OPNsense, they used a FreeBSD that had the libreSSL in their base system, not sure though, and they switched to OpenSSL somewhere in the history.

thanks

Thank you for your quick reply.

But that is not my question. My question was not about the severity of this vul., nor the plan of OPenSSL.org, but about the OPNsense's plan to patch it.

Anyhow, your reply is highly appreciated.

Any answers about the OPnsense patching plan would be appreciated.

New Year to All.

I noticed that the Vulnerability of OpenSSl111.1.1.1w still not fixed the latest release. See the following snippet.

Do we have some schedule or plan to get this patched?

Appreciate it!

"
Currently running OPNsense 23.7.11 at Tue Jan  9 12:40:00 EST 2024
vulnxml file up-to-date
openssl111-1.1.1w is vulnerable:
  OpenSSL -- DoS in DH generation
  CVE: CVE-2023-5678
  WWW: https://vuxml.freebsd.org/freebsd/a5956603-7e4f-11ee-9df6-84a93843eb75.html

1 problem(s) in 1 installed package(s) found.
***DONE***
"

Thank you new sense for the kind reply.

I may use the 23.7, even though I am not sure it's a good idea to load this 23.7 right away.

Anyhow, I am still curious about how to remove the openssjh-9.3.p1, not touching the opnsense kernel for sure.

Moreover, can we upgrade to 23.7 directly from 23.1.11? Cause we know 23.7 is on FreeBSD 13.2,  23.1.11 on 13.1. 

I assume my current HW running 23.1.11 would be fine with the 23.7. Please correct me if not.

Thanks a lot

Hello,

I sent this question to a guru. He is probably on vacation I guess. So I am posting it here

I recently installed OPNsense 23.1.11, and the security auditing showed one vulnerability related the default openssh-portable-9.3.p1. So I downloaded the openssh-9.3.p2, trying to avoid the vulnerability. The new openssh is working.

Now the auditing still shows the vulnerable 9.3.p1.  So I tried to remove the old 9.3.p1, it always tells me it would remove the opnsense kernel 23.1.11 as well.

So, is there a way to just remove the openssh-9.3.p1 without touching the opnsense 23.1.11? or is it safe to keep the old p2?

Appreciate it

Buddy S.