Messages

I'm encountering the same situation. Surely this isn't the desired behavior, right? I mean, what's the point of putting in the Cloudflare API key if you have to manually create the TXT record?

I'm on:

OPNsense 24.1.6-amd64
FreeBSD 13.2-RELEASE-p11
OpenSSL 3.0.13

Sorry to necrobump, but is this tutorial still accurate? I'm asking because I've followed the instructions and IPv6 isn't working for me. I'm trying to assess if the issue is with my configuration or if it's more general. I'm getting the IPv6 only on WAN, but nothing on LAN devices. What's worse, enabling IPv6 seems to be breaking my otherwise functioning HAProxy.

I've opened a bug report and the guys from SunnyValley were fast to reply. It seems that the packet engine is crashing. They gave me a debug binary which generated some logs, that were sent to them.

After activating Sensei I've experienced the same behavior and sent a bug report. Thank you again for mentioning it!

I really would, but after uninstalling Sensei I cleaned up the system, so there are no logs to send.
Anyway, I've reinstalled it and set it to reporting only.
I did that in the past too, and I kept getting disconnects.
I will wait to see when I get the first disconnect in the monitoring system and try to report a bug.
Thanks for the idea!

Hello,

I'm running:

OPNsense 22.1.6-amd64
FreeBSD 13.0-STABLE
OpenSSL 1.1.1n 15 Mar 2022

on:

Intel(R) Core(TM) i5-4570 CPU @ 3.20GHz (4 cores, 4 threads) with 16GB RAM.
My ISP offers a 1 Gbps connection with PPPoE authentication and dynamic IP address.

I have Zenarmor(Sensei) installed and configured(on LAN interfaces) for some time now and it's been working perfect, but for about 2 weeks I keep getting 3 daily disconnects within the same time range with random behavior.
Time range:

• In the morning: between 10:00 to 11:00
• Evening: 19:00
• Night: 03:00

Random behavior: Sometimes all the LAN clients can't access the internet but the WAN connection doesn't change the IP address. Sometimes the WAN IP get's changed, meaning the PPPoE connection has been reinitialized.

It's not a big deal, but it's annoying especially if I'm working from home and have a VPN connection to the office, or my outgoing ssh connections from other servers get dropped.

I've checked the cron and I don't have anything running around that time.
I've arrived at the conclusion that Sensei is to blame after uninstalling it and seeing the issues disappear for a couple of days and having the issues reappear immediately after reinstalling.

Has anyone else experienced this sort of behavior?

Nu-i ashe ?

Salut!

Ca si in celalalt thread, postez pentru cine da din greseala peste aceste intrebari.
Tocmai am rulat un speedtest din spatele OPNsense si acesta este rezultatul https://www.speedtest.net/result/12032620736
OPNsense functioneaza foarte bine cu conexiunea PPPoE de la Digi.

Salut!

Motivul pentru care postez este sa nu se lase impresia ca OPNsense are probleme de performanta cu conexiunea gigabit.
Eu il folosesc si pe clienti transfer cu 8-900 mbps(si am multe servicii activate pe OPNsense).
Problema in acest caz imi pare a fi adaptorul acela USB-RJ45. Poate nu este gigabit, poate nu are driverul bun, poate este conectat intr-un port USB 2.0.

I thought I should try maltrail with the work-around of daily restarting the maltrail sensor from cron but I have noticed two things.

1. In high traffic periods restarting only once per day wasn't enough. I had to modify the cron to run hourly.
2. After a couple of days I found multiple maltrail sensor orphaned processes which I had to kill manually from cli.

You are not alone in this situation  :D
Check this https://forum.opnsense.org/index.php?topic=24345.0

Hello,

I'm running both HAproxy and Unbound without any issues at the moment. I experienced something like what you are describing a while back and the trick was to bind haproxy to LAN and do a portforward from WAN for the service. Ever since I haven't had any issues.
Hope it helps!

I'm also following the github issue for maltrail to see if there are any solutions, but I'm already used to this OOM behavior. It isn't the first time this has happened to me with maltrail and OPNsense. Even in older versions of OPNsense(unfortunately I don't remember if it was running on python2 as requested on github) I would find the box consumed of all the RAM. That's why I'm used to disabling it and only testing to see if the issue has been corrected from time to time. For now the two proposed work-arounds seem to be using:
1. cronjob - to restart the maltrail sensor process
2. monit - to check the RAM consumption and do something like the cronjob

Let's hope for a quick fix  ;D

Useful info thanks. Question: what was your rationale for wanting to move to ZFS?

In my case I have often power outages and on UFS the file system would get corrupted leading to OPNsense not booting and I would have to take the OPNsense box from the closet in order to connect it to a monitor and debug. I tried multiple configurations for UFS but nothing worked. Since using ZFS the power outage and corruption situation hasn't been an issue.

Hello!

I seem to experience the same issue with similar hardware(4 cores, 16GB RAM), 1 Gbit PPPoE WAN and latest version of everything from the official Community repo.
I don't know what triggers it, sometimes it works fine for a couple of days and then it starts eating up all the memory. I tried different values for Maltrail - Sensor - Capture Buffer Size, but it doesn't seem to do anything regarding the problem. Luckly, OPNsense still works even if Maltrail consumes all RAM and SWAP, so I can connect(webGUI or ssh) and kill the sensor processes. I think I will disable Maltrail and wait for an update, since for my setup it's more of a nice to have, than a must.