Messages

16

23.1 Legacy Series / Re: Mobile clients config not working in 23.1

« on: January 31, 2023, 02:17:23 pm »

23.1_6 fixed my issue with IPSec connections being awfully slow to establish, like taking a good 30 seconds for a mobile device to connect home via IPSec. Was going crazy over the configuration to find out why it was taking so long.
Just updated and now connections are established in 1-2 seconds again.

17

Zenarmor (Sensei) / Re: Issues since Update to 1.12

« on: November 06, 2022, 07:11:54 am »

Not sure if it is related, but I’m seeing issues in resolving my local DNS domain where DNS queries are being blocked for that particular domain only. It usually starts after a couple of hours and can then only get it to work again when restarting Zenarmor. It will then work for like 12-20 hours before it fails again.
All other DNS works fine, only the domain I use for my internal hosts is affected… very strange.

18

Zenarmor (Sensei) / Re: TLS blocking page

« on: November 01, 2022, 09:03:58 pm »

You should be able to download the root certificate with practically every modern browser.

That said, it’d be cool if we could configure Zenarmor to use an existing OPNsense CA to generate the certificates instead of using its own internal CA.

19

Zenarmor (Sensei) / Re: Sensei - External elastic search - socket/open file descriptors exhaustion

« on: August 18, 2021, 11:31:15 am »

Might well be the same issue as this one I had earlier: https://forum.opnsense.org/index.php?topic=23786.0

I've moved to local Elasticsearch as there wasn't really any progress in finding out why it's hugging up that much memory over time, but I guess there is a chance the underlying issue is the same as for your TCP sockets.

20

Zenarmor (Sensei) / Re: Sensei ipdrstreamer.py memory usage

« on: July 04, 2021, 09:53:56 pm »

Sure, report send.

21

Zenarmor (Sensei) / Sensei ipdrstreamer.py memory usage

« on: July 04, 2021, 08:45:33 am »

On my "Home" install with remote Elasticsearch I see ipdrstreamer.py consuming increasing amounts of memory (in the order of >4 GB) until it is finally OOM-killed and starts over. I've already increased my OPNsense VM memory to 8 GB, but that still doesn't seem to be enough and I see ipdrstreamer.py being oom-killed about once every day.
Looks more like a memory leak to me than normal usage to be honest.
Is Sensei supposed to be using that much memory if the Elasticsearch is actually remote on another VM?

Sensei has observed 76 unique devices on my network and I have a 100Mbit connection which however is barely utilized to max as you would expect from a home network.

22

21.1 Legacy Series / Re: Massive spike in states every day around 00:15am killing WAN connection

« on: June 27, 2021, 10:05:08 am »

I found it, took a while though.
I'm running *sense virtualized on Proxmox, and while switching from pfSense to OPNsense, I missed to disable the VM backup for pfSense. Every night at 00:15 Proxmox would try to spin up the pfSense VM for backup and as I PCI passthrough the network adapter for WAN, that would mess with the passthrough and the OPNsense VM would lose access to the device. Everything else was just symptoms... works fine now.  

23

21.1 Legacy Series / Massive spike in states every day around 00:15am killing WAN connection

« on: June 24, 2021, 07:23:40 am »

I've recently switched from pfSense to OPNsense, running 21.1.7_1-amd64.
For the last days, every night at 00:15am I see a huge spike in state entries (like hundreds of thousands) which kills the connection to my DSL modem and hence causes WAN connectivity to go dark until I reboot the firewall in the morning.
Currently struggling to find out what causes this, as there is no corresponding traffic spike on any interface, the only other indication is a spike of outpass6 packets on WAN. From what I can see it looks like these connections are coming from the firewall itself, which makes sense given nothing else has changed on my network in terms of services, so there's no reason there should be more traffic from any of the running clients now that I switched to OPNsense, as with pfSense this never happened.

For what it's worth, I run sensei on LAN and suricata on LAN (but not in IPS mode) and as I see a huge number of DNS related connections outgoing during the concerning time, it might be worth mentioning that I also have some DNSBL lists configured in Unbound. No custom ones though, just selected a couple of the blocklist.site pre-configured ones. The DNS queries are inconclusive though, it seems to be mostly unbound contacting various root-servers, so maybe it is just trying to resolve a great amount of queries, for which however I have not seen any client-queries coming through. I have query log enabled and pipe the whole stuff into pfElk, so at least I have some visibility, but there's no real indicator of what would be going on.

In pfElk I can see a spike of firewall events between 00:15 and 00:16 which are all "pass" events, so nothing is getting blocked. Looking up the IP addresses, it is a large amount of IPv6 destination IPs (which explains the outpass6 packets spike) and if I search for these, it is all *.root-servers.net, so I guess it's really unbound related, the question is however what triggers it.
Within the time window where Unbound seems to generate 18.000 firewall entries for various root servers, I only see 180 client-side DNS requests in the query log, so those numbers don't match up, unless Unbound is querying root-servers for a completely different reason.
The firewall is running smooth throughout the whole day otherwise, just shortly after midnight it seems to go haywire.

Anyone have any ideas?