Messages

I was already wondering how a dnat bug hadn't been noticed during testing. But when combined with divert-to, it makes sense. I'm glad the bug has now been found. Thanks

I had a similar experience. I also have DNAT for a Host and divert-to. After the update this stopped working.

Sorry.
Can you confirm that DestNAT (IPv4) is working on your side?

@Patrick:
Can you confirm that DestNAT (IPv4) on your side? In my setup it did not work. I try to figure out if i have a config issue that still worked with 26.1.11_10 or if its version related.

I have migrated all rules to the new rules. Including NAT and everything. Worked fine.
Today i had to rollback a snapshot for the first time since DestNAT for IPv4 stopped working entirely.
I copied my existing rule and saved but it still was broken.

After rolling back DestNAT was working again.

EDIT:
I migrated my rules and NAT rules to new a while ago.

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.