Messages

As far as I can remember, there's already a similar thread regarding the suspected hacking attack on your OPNsense. Making such claims about your internet service provider is a pretty bold statement.

If you're right, I'd switch internet service providers. But you should definitely have proof that holds up in court regarding the suspected hacking.

Based on what you've written, I don't think you were hacked. Why would a hacker waste their time or use special exploits?

resetting the squid cache, killing the process in the console and restarting might have solves this. very odd.
i will mark this as solved.

Env:

Versions
OPNsense 25.1.6_2-amd64
FreeBSD 14.2-RELEASE-p3
OpenSSL 3.0.16

After upgrading to 25.1.6_2-amd64, squid does not work any longer.
killing the process and restarting it makes it work for a few seconds. The process itself is running but clients get nothing back. "% [Waiting for headers] [Waiting for headers] [Waiting for headers] [Connectin..."

Code Select Expand

root@OPNsense:~ # configctl proxy start
template reload Deciso/Proxy: OK
template reload OPNsense/ProxySSO: OK
Segmentation fault
Starting squid.
__ok__


but doesnt process requests after a few seconds.

Same here:

Versions
OPNsense 25.1.5_5-amd64
FreeBSD 14.2-RELEASE-p2
OpenSSL 3.0.16


no details in alert window. Its just empty.

I was also failing with the plugin, it only works if you use Authentication in addition. Notwork-only doesnt work ... no idea why

what do you mean with "Authentication in addition" in my use case all my servers/clients use credentials and authentication is configured in opnsense (local users). Please take a look at the github issue. i included screenshots that show my configuration.

https://github.com/opnsense/plugins/issues/4565


Only HTTP access control works. HTTPs access control does not. Squid does work with https. The CA is installed on the clients. But the user auth is not logged and not send to the access control so the policy doesnt grip.
When using sni-logging https does work also.

IT is NOT a SSL inspection issue itself. Because SSL is processed as usual in squid and also cached. Only the access control part for users and groups does not work in HTTPS.

Is nobody else using access control with https inspection?

I thought I had provided all the information needed to replicate the problem. What can I do to solve the problem?

after updating to OPNsense 25.1.4_1-amd64 and suricata 7.0.10 again it works again.
Did 25.1.4_1 change anything? The hotfix is not listed.

opnsense-revert -r 25.1.3 suricata

this fixed it. the logfiles reappeared.

Suricata is blocking but not logging its actions.

After the update to 25.1.4 suricata doesnt create the "latest.log" anymore. Also the "suricata_" does not contain any helping info.
The logfiles also can not be viewed in the webinterface. The spinner is constantly running. even after resetting all logfiles in OPNsense.

I hope Ad will take a look at the issue on github.

The squid proxy config itself works as expected.

But i have problems with the www/OPNproxy plugin.

Hello Patrick,


Im not using a transparent Proxy, i use SSL inspection. My CA is installed on my clients. Squid logs all requests (HTTP/HTTPs).

"Are you aware of the constraints SSL inspections brings?"
Which constraints beside the local CA deployment work?

After doing some testing i discovered that blocking HTTP like: "http://opnsense.org" works as expected. But HTTPs does not. For example "https://opnsense.org", which also should be blocked by the "*" rule doesnt work. HTTPs content can be browsed.

Hallo Zusammen,


seit 2018 nutze ich OPNsense. Das es eine deutschsparachige Usergroup ist mir erst vor kurzem bewusst geworden.
Ich freue mich auf den Austausch.