Recent posts

#1
We upgraded the firmware (BIOS) on one of our DEC3852 to the newest version. The appliance has 16 GB of RAM, but after the update only 8 GB are present. Is there something to do after the update? Unfortunately I have no access to the console at the moment, so it would be good to know if I missed something or if this is an coinsidence with a hardware defect.
#2
French - Français / Configuration Pare feu - Début...
Last post by Titus91 - Today at 01:24:37 PM
Bonjour à tous,

Je suis débutant dans le domaine, j'ai donné à mon OpnSense 3 interfaces réseaux. Un LAN avec un PC dedans en 192.168.1.3, un WAN en 172.16.1.74 et une DMZ en 192.168.255.189.

Je voudrais donner à mon LAN accès à internet mais je n'y arrive pas du tout si quelqu'un pouvais m'aiguiller ce serait génial.

En remerciant par avance pour l'aide apporté.
#3
Portuguese - Português / Permissões
Last post by tullerbr - Today at 01:23:30 PM
Bom dia pessoal, eu estou montando um opnsense ultima versão e queria uma dica de voces.

eu quero poder permitir um usario especifico que ele consiga mudar a lan mas nao mudar a wan, pois que percebi ou vc oculta tudo ou vc mostra inteira a parte de interfaces, se alguem tiver feito o como fazer me ajudaria e muito
#4
25.7 Series / Re: Update not working - Host ...
Last post by franco - Today at 01:05:21 PM
Looks good :)
#5
25.7 Series / Re: Looking for testers Q-Feed...
Last post by Q-Feeds - Today at 12:50:22 PM
We've checked the logs you've send over and here are our first findings:

  • High false positive risk IOCs: Some of the addresses weren't included in our feed because they score high on false-positive risk. For example, GitHub IPs, Google bots, and other cloud infrastructure. While blocking these could work in some setups, it could disrupt others. We intentionally exclude them to reduce potential support pressure and avoid accidental outages. This ensures our feed is reliable for a wide range of users rather than only aggressive environments.
  • FireHOL lists: FireHOL contains very large subnets, which can cause a lot of false positives. They themselves recommend using their lists for enrichment rather than direct blocking if I'm not mistaken.. Blocking whole /16 or /8 subnets is extremely risky for production networks, which is why our feed focuses on more precise, actionable IOCs. It does create a lot of hits though ;-)
    • Warning for those unfamiliar: FireHOL 1 also contains RFC1918 private addresses never use it outside of WAN interfaces unless you know what you're doing.
  • Older known IOCs: Some addresses were excluded because they've been known for a long time and are often already mitigated by other protections. We've adjusted our algorithms to stretch coverage safely where it makes sense, but the goal is always to maximize real threat protection without introducing unnecessary noise.
  • Focus on real threats: The "missing" addresses are mostly potentially unwanted traffic but not truly dangerous. Our feed prioritizes high-confidence threats as much as possible, so users aren't blocked by mass "noise" like search engine bots, proxies, or reused cloud IPs. Benchmarking purely by count can be misleading, blocking one actual APT attack is worth far more than tens of thousands of minor unwanted connections for us.
  • Complementary lists: There's no "one list to rule them all." Q-Feeds is optimized for precision, but free lists like FireHOL or Spamhaus DROP can still be valuable for enrichment or as an extra layer for some situations and users. Using them together is a solid strategy.

That said, your feedback is very useful, and we can continue looking at those edge cases to improve coverage where it makes sense.
Thanks again for your detailed testing really helps us improve!
#6
What you are trying is not going to work:

For a transparent proxy to work and break up TLS traffic, you need your own CA (i.e. self-signed certificate and corresponding private key) to create certificates on-the-fly while the traffic passes through the proxy. Actually, there are two TLS connections: one from your PC to the proxy and one from the proxy to the website. The first connection is where the problem arises: Your PC requests a website (e.g. "xyz.domain.com") and expects to get a valid (i.e. "trusted") certificate for it.

This is where the proxy creates a certificate for xyz.domain.com and presents it to your PC. In order to be trusted, the CA the certificate was created with has to be added to the trust store of the PC.

In practice, that means you can only use your own CA to do this and you have to make sure that each LAN client trusts that CA. Apart from that, there are certain sites that do not want to have their traffic inspected (like banks) and use mechanisms to enforce that this will not happen, like certificate pinning or at least, by having a CAA DNS entry that show the CAs which may hand out certificates for a specific domain in the first place - such that your own CA will never work. For each of these types of websites, you have to create an exemption list (aka SSL bump sites). Also, for some clients (like IoT devices), you cannot even change the trusted CA list, so those clients have to be exempt from inspecting traffic as well.

All in all, this is something that needs a lot of work to get going and therefore is mostly used in business environments. For most end-user applications, it is practically not feasible.

What is worse, is that you misinterpreted what a LetsEncrypt certificate is about: You can only have normal certificates (not CA certificates) signed by LetsEncrypt - and only if you can verify that you own that specific domain. So, you cannot make use of LetsEncrypt within a transparent proxy context at all, no matter how hard you may try.
#7
Hey Tamas,

glad you got it working. I'm happy if this deepened your personal Ipsec troubleshooting skills.

If there is any oversight in the linked documentation, please give a hint and we can implement some additional tip boxes.

Since client requirements evolve pver time, the documentation is never perfect.

https://github.com/opnsense/docs/blob/master/source/manual/how-tos/ipsec-swanctl-rw-ikev2-eap-mschapv2.rst

#8
You need to create your own private CA for transparent proxying of TLS. This part of the error messages hints at that:

2025/10/14 10:28:41| FATAL: No valid signing certificate configured for HTTP_port 127.0.0.1:3128

"signing certificate" == CA

HTH,
Patrick
#9
Hi there,

All is up to date.

I'm tuck to enable squid proxy (transparent) with a "Let's encrypt" certificate.
Everything was working nice.
- ACME plugin
- certificate creation/installation. No errors.

I can use my certificate in "system/settings/administration" and access opnsense with my domain.

Squid Proxy is UP (green play button) is I let the opensense "own signed" certificate but as soon as I use the "let's encrypt" one, I got "red square button".
If I click on start I get:

Segmentation fault
Starting squid.
CPU Usage: 0.009 seconds = 0.009 user + 0.000 sys
Maximum Resident Size: 65824 KB
Page faults with physical i/o: 0
2025/10/14 10:28:41| Processing Configuration File: /usr/local/etc/squid/squid.conf (depth 0)
2025/10/14 10:28:41| Starting Authentication on port 127.0.0.1:3128
2025/10/14 10:28:41| Disabling Authentication on port 127.0.0.1:3128 (interception enabled)
2025/10/14 10:28:41| Starting Authentication on port [::1]:3128
2025/10/14 10:28:41| Disabling Authentication on port [::1]:3128 (interception enabled)
2025/10/14 10:28:41| Starting Authentication on port 127.0.0.1:3129
2025/10/14 10:28:41| Disabling Authentication on port 127.0.0.1:3129 (interception enabled)
2025/10/14 10:28:41| Starting Authentication on port [::1]:3129
2025/10/14 10:28:41| Disabling Authentication on port [::1]:3129 (interception enabled)
2025/10/14 10:28:41| WARNING: empty ACL: acl bump_nobumpsites ssl::server_name "/usr/local/etc/squid/nobumpsites.acl"
2025/10/14 10:28:41| Processing Configuration File: /usr/local/etc/squid/pre-auth/40-snmp.conf (depth 1)
2025/10/14 10:28:41| Processing Configuration File: /usr/local/etc/squid/pre-auth/dummy.conf (depth 1)
2025/10/14 10:28:41| Processing Configuration File: /usr/local/etc/squid/pre-auth/parentproxy.conf (depth 1)
2025/10/14 10:28:41| Processing Configuration File: /usr/local/etc/squid/auth/dummy.conf (depth 1)
2025/10/14 10:28:41| Processing Configuration File: /usr/local/etc/squid/post-auth/dummy.conf (depth 1)
2025/10/14 10:28:41| WARNING: HTTP requires the use of Via
2025/10/14 10:28:41| WARNING: 'HTTP_port 127.0.0.1:3128' missing private key in '/var/squid/ssl/ca.pem'
2025/10/14 10:28:41| Not currently OK to rewrite swap log.
2025/10/14 10:28:41| storeDirWriteCleanLogs: Operation aborted.
2025/10/14 10:28:41| FATAL: No valid signing certificate configured for HTTP_port 127.0.0.1:3128
2025/10/14 10:28:41| Squid Cache (Version 6.14): Terminated abnormally.
/usr/local/etc/rc.d/squid: WARNING: failed to start squid

I search and I tried to understand but I'm completely stuck.
May be a wrong parameter on the certificate (I mean certificate is valid but Squid was waiting for a special value?).
I really don't know what to do.

Thanks a lot for any help

#10
care to share how it has been made to work ?