Messages

dear, it is with a sense of dread i write this post as it concerns opnsense going haywire repeatedly


the logs reviewed thus far do not contain a clear indicator of what happened, but it never happens once, this is time three in just two weeks. For all cases over time the scheduled updates for suricata appear to correlate in time, except today and this time it is even more bad than just unbound and suricata dying.


i've now initiated the update for 20.7.4 which i had not done before since it only presented a pkg update


my question is if others experience such crashes as well, my concern is it may not be just instability of opnsense but an external factor. if so, there are not indicators left in the logs

Think i cracked the problem.

core issue


1) dhcp scope did have a gateway set but not a router
2) manually setting dhcp option 3 to type IP and the ip address for the LAN interface appears to work

depending issues

1) IDS crash on rule update fail = to all appearances, is fixed now (crash because of DNS fail !)
2) unbound flapping = improvement, not fixed

This approach did indeed remediate all issues mentioned.

Unbound remains flakey due to some configuration glitch between proxmox and unbound wrt route preferences.

Yes, I could have deployed test instance of OPNsense. But before doing so, I would like to know what to expect and which way is better one  8)

well eh, deploying a throw away VM with 20.7 is the prferrable way if you are curious

Think i cracked the problem.

core issue


1) dhcp scope did have a gateway set but not
2) manually setting dhcp option 3 to type IP and the ip address for the LAN interface appears to work

depending issues

1) IDS crash on rule update fail = to all appearances, is fixed now
2) unbound flapping = improvement, not fixed

If you have the ability to deploy a test machine with 20.7 i'd go ahead with that, it appears to not yet have been fully stabilzed in some ways

By slow I mean a drop from 1.95Gbs to 0.915Gbs, 50% reduction.
In 20.1.x I was seeing about 1.7Gbs, so much less drop when netmap enabled.

I only showed the Suricata on LAN.  I'll re-run with sensei normal and bypass more and send the results.   By the way, my ELK stack is on another ESXI with a 10Gbs link, so the ELK CPU/Memory load will not impact opnsense/sensei.

this is normal for an IDS, it inspects every packet, if you enable all rules this is even optimistic. disabling some rules may show a noticeable performance increase with IDS enabled

   
• with Unbound service there are recurrent issues where the service simply stops responding
• dns lookups from the opnsense web-ui from any interface work as per normal
• this makes me think the problem does originate within unbound

Validating the unbound configuration i could not find any blacklist enabled. Rebooting opnsense i could find the domains which return 0.0.0.0 as address briefly do resolve correctly. The IDS was not enabled at the time since it had crashed once more, also when disabling the IDS there was no change observed for the dns queries erroneous results.

Hey Mark,

This time i got lucky, so to speak. The opnsense VM went all goobly goo again.

The IDS service crashed and rebooting showed a massive amount of errors and flaws. The fw had been running peachy for hours upto the mistake of assigning an invalid ip as dns server in a dhcp scope.

It is the only change i can think of that happened at the time. The console was again filed with swap fail messages.What happened hours before is i had

1) enabled the 2GB swap space flag to make sure i  would not have any memory issues. The VM has 2.5GB of ram to run dhcpd, suricate, ntpd, unbound which i think should be adequate. Since the services only appear to crash on memory depletion enable swap seemed to be a good idea.

2) set the VM to run with SEABIOS and 440fx (i just noticed it had QXL set as displa which i don't think is sensible but it I have now powered off the opnsense VM and assigned virtio/scsi single and have set display to standard vga.

If anything goes wrong again it will take more hours for this to happen. What i do notice is during this time the memory consumption soars from around 800MB to 2.1GB and more.

Dear,

Using opnsense since release 17 or so i find it unstable to work with on Proxmox VE 6.2

the disk i/o is troublesome to the point only selecting IDE with SSD emulation appears to work well (for speed), choosing a differen kind of controller results in a lot of swap fail notification.

on shutdown there are a plethora of errors thrown which appear low level, regardless of the controller chosen

in all i don't feel like 20.7 is as production ready as one typically assumes

memory consumption appears quite high out of the box, the VM has 2.5GB of ram and frequently starts complaining it is out of swap space shutting down multiple services without warning

Dear,

Confronted with Zberp being reported as originating from my SmartTV reaching in relation to Netflix traffic (yes, port 80) I came to look at Suricata SID 2021831 which is a flowbits:noalert rule

It took me a while and had to ask but someone pointed out this rule is not supposed to trigger since it is a flowbits rule for which no alert is configured. Hence i wondered if this (most likely) is my mistake of enabling such rule or if this is a known error in the suricata configuration with OPNSense.

Thank you

Staat reply-to WAN niet gewoon uit ?

Did you try setting "automatic outbound nat" under nat ?

Management interface is WebGUI, which is only available on LAN.


I'm not sure how to read the routing table in opnsense. Since i have not configured any manual routes and did not alter the non-blocking rules i'm not sure how a loop route could come into existence.

Het lijkt me niet wenselijk de opnsense vroeger op het internet te zetten dan de FritzBox. Tenslotte moet de FB toch de DSL omzetten, niet ?

Dear,


After blaming opnsense i came to realize it is most likely all on me, the slow loading of the WebGUI.


I don't see how to start troubleshooting this. There appears no indication thus far. When i do a factory reset the WebGUI is snappy as expected.


This setup has a WAN - LAN - OPT interface setup, Unbound DNS is set to query WAN and Localhost.


The slow actions is the same over IP or DNS for the management interface. There is no other interface listening to the management interface.


I suspect this may be a routing issue or gateway weighting issue but could not find anything related.


Best Regards,


Joris