Messages

I've already opened a feature request on GitHub and would like to discuss it here in the forum.

In the current OpenVPN version, it's now possible to open the listening socket on multiple IP addresses. This is a change from the previous behavior, where the socket could only be opened either on all IP addresses and interfaces or on a single IP address.

In my case, I have additional IPs on the WAN interface (IPv4 and IPv6 addresses) that I intend to use for VPN clients: IPSec, OpenVPN, and WireGuard. So far, I can only have the OpenVPN server listen on, for example, a single IPv4 address.

With the new OpenVPN version included in the current OPNsense release, it is possible for a server to listen on different IPs; you can specify this in the configuration by using an array, for example.

In the OpenVPN configuration, this would look like this:

Code Select Expand

local 10.10.10.10 1194
local 2001:db8::1 1194
What do you think?

Github Issue:
https://github.com/opnsense/core/issues/10376

News article:
https://www.heise.de/en/news/OpenVPN-2-7-0-with-multi-socket-support-and-new-Windows-driver-11174406.html

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.