Messages

1

Sensei / Re: Sensei on OPNsense - Application based filtering

« on: July 28, 2020, 06:03:55 am »

Hi donato,

Yes, this is expected. Fix is easy. Below commands should fix it:

Code: [Select]

pkg remove os-sunnyvalley
pkg install os-sunnyvalley
pkg install -f -y os-sensei
If db is elasticsearch:

Code: [Select]

pkg remove elasticsearch5
pkg autoremove
pkg install elasticsearch5
Mongodb:

Code: [Select]

pkg remove mongodb40
pkg autoremove
pkg install mongodb40
All these are currently being built into the software to handle the upgrade automatically. More on this later tomorrow.

On the other hand, before proceeding with the above commands, can you shoot a PR? We'd like to have a look at a few files.

I missed what you said about the PR until after I ran the first three commands. I sent it anyway even though it's in the middle of updating the SunnyValley repository catalogue. Hopefully it still helps.

2

Sensei / Re: Sensei on OPNsense - Application based filtering

« on: July 28, 2020, 05:18:56 am »

Dear Sensei users,

OPNsense 20.7 is set to be released this week Thursday.

This is a major upgrade.OPNsense will be switching to FreeBSD/HardenedBSD 12.

We're taking the necessary steps for this upgrade to proceed as smooth as possible. Having said that, please stay tuned for further updates on this. We advise to postpone 20.7 upgrade for a few days so that we can fully confirm the upgrade is compatible with Sensei.

Should we submit bug reports if Sensei Packet Engine wont' start cuz we upgraded to 20.7 early and didn't see this or is it known that it isn't working?

For me Sensei Packet engine fails on starting and I get a popup that let's me report it's not working but then nothing pops up.

3

Sensei / Re: Sensei on OPNsense - Application based filtering

« on: July 12, 2020, 10:27:57 pm »

Hi @Rickytr, it's not expected. Does resetting reporting help ? (Sensei -> Configuration -> Reports & Data -> Reset Reporging)

I have the same problem. Resetting the reports does not solve the problem.

Live session explorer of connections and TLS works though. It's failing in DNS and Blocks.

Edit. Solved after opening a bug report.

Reported bug through the GUI with my logs.

I also have the same problem. I think the issue is the live blocked sessions explorer is now missing all the columns such as start, end, source IP, protocol. Now it shows the columns you expect on the overview page such as "alerts - top blocks" "top remote hosts" Checking all those shows undefined and there is  loaded record counter. So the data is there but the web page for it is missing the columns it needs to show the data.

Live blocked sessions. https://imgur.com/a/B1qt9EP
Here are the columsn in every other live report.  https://imgur.com/a/IKIz8Ec

4

Sensei / Re: Sensei on OPNsense - Application based filtering

« on: May 02, 2020, 10:34:33 pm »

Hi opnsense community.

I'm facing a strange issue with Sensei and VLANs. After every reboot as soon as Sensei is started I loose every connectivity on VLAN interfaces.
I need to login via non-VLAN assigned interface, restart Sensei and then it works again.

Anybody with an similar issue?

I've already filed a bug to the SunnyValley Helpdesk.

br

For the vlans are you adding the vlans themselves to the protected interface or the physical interface the vlans are on. Make sure you aren't doing both. I was having this bug to and I was just adding the physical interface. It didn't happen all the time. As soon as it happens send the bug report over so they have more reports than just mine.

Since It last happened to me I think mb and team told me in the ticket they found an issue with netmap when sensei packet engine started at startup. I have since created a bridge from my firewall to my switch, mainly to increase bandwidth and now the bridge interface isn't even an option in Sensei but I can add all the vlans and I haven't had the problem since.

One workaround I did before the bridge though was to turn Sensei auto startup off, and turn sensei back on manually after a reboot. It's not ideal but it's something. You could probably make a cron job to start the packet engine everyday at a certain time that way in case you forget to turn it on after a reboot it can turn on with the job.

5

20.1 Legacy Series / Unbound Access Lists with DHCP-PD subnets

« on: March 24, 2020, 12:02:50 am »

So I think I found out why unbound eventually starts refusing my lookup requests over IPV6.
When it stops working and I do an nslookup from Windows I get a "query refused" immediately.
It seems to happen anytime my IPV6 address from my ISP changes. Restarting Unbound fixes the issue immediately since Unbound reloads all the current internal network address ranges.

Is it possible to get an unbound reload to kick off whenever DHCP6 has to change addresses on my WAN port thus changing them on all my internal networks?

If not as long as I don't open my dns up on firewall can I just add 2605:e000::/32 to my allow list since that's Charter's prefix and my internal networks should always fall under those networks. As far as I understand this would allow anyone on charter to use my dns but as long as I never open it up in firewall they still can't use my dns server.

I should mention when this happens dns over ipv4 still works, but I believe part of the problems I've been having lately with slow lookups have been the pc or browser taking it's time to failover from ipv6 to ipv4.

6

19.7 Legacy Series / Re: VPN Help

« on: January 25, 2020, 06:40:41 am »

You don't happen to have any outbound NAT policies that are possibly changing the IP address of the VPN server to a public IP do you?

Edit: Actually looking closer you have a rule to allow your LAN to talk to the server, but do you have a rule on OPT1 to allow your server to talk to the LAN?

7

Development and Code Review / Re: UniFi Controller

« on: January 24, 2020, 05:27:05 am »

if it is a "plugin" then it will serve both, those that like or those that dont want it...

it is a choice
id bet there are probably alot of Ubiquiti owners using opnsense instead of USG

Yes we exist but moving to Opnsense also makes me want to move to Aruba or something else on the switching end. I'm tired of my cloud key needing its firmware reset. I won't put that buggy software anywhere near my firewall.

8

Sensei / Re: Sensei on OPNsense - Application based filtering

« on: January 20, 2020, 06:57:47 am »

After restarting the firewall, the network connection on an interface no longer worked.
I unfortunately had to completely uninstall sensei so that my firewall could connect again.
I do not know why.

I will not install sensei now until the problem is finally fixed. sorry ...

I reported on this issue months ago. I must have had a config that tripped it more often than others.
What I found was to leave the auto start for the Sensei Packet engine off then after a restart everything is fine you just need to go in and start sensei manually. I also keep an unprotected interface free now so I can just swap my pc to the second drop I have nearby so I can get in the router to fix it.

9

Sensei / Re: Sensei on OPNsense - Application based filtering

« on: December 05, 2019, 02:39:08 am »

@mb I'm running into that bug that I reported back during beta again. The one where after a reboot of OPNSense once the Sensei Packet Engine starts it cuts off all traffic to protected interfaces. I have to use another interface to restart the Sensei Packet engine. I also verified it did this again with "Enable engine heartbeat monitoring:" turned off or on.

I did submit a report through the interface with logs. Hopefully that helps.

10

Sensei / Re: Sensei on OPNsense - Application based filtering

« on: November 29, 2019, 10:33:48 pm »

@mb this is great. The 50 device home limit should work for me depending on how sensei handles things. Even better that I can purchase right through the interface and use google pay to pay.

11

Sensei / Re: Sensei on OPNsense - Application based filtering

« on: November 26, 2019, 02:45:57 am »

@donatom3, which devices would be out-of-scope is random and dependent on the memory state buffers. With device identification we'll enable user to select which devices to cover. For now, a higher tier would be more suitable. Also note that only IPv4 addresses  count, so if you have a dual stack, it won't affect memory buffer limits.

Having said that, as a gratitude to our BETA users like you, we'll be providing a suitable discount for higher tiers so that it would still be in the lower tier price range. More on this next week.

@MB Can't wait for the home/discounted licensing.

Once Sensei can be integrated with firewall and routing rules I'll be able to start selling management on OPNSense + Sensei as an alternate offering for our customers. So it will be good if I can show them what it can pick up and report on.

12

Sensei / Re: Sensei on OPNsense - Application based filtering

« on: November 22, 2019, 04:56:21 am »

@MB

How does soho work with the 15 device limit for those of us with well over that on our home networks?
Do we pick and choose what's protected or is it any device that's on the protected interface?

13

Sensei / Re: Sensei on OPNsense - Application based filtering

« on: July 18, 2019, 04:14:19 am »

@mb

So after the upgrade to 19.7 release I was able to change my tunables back to 4096 for rx and tx.

Here is the issue. And I've seen this on a few upgrades with no changes but firmware or sensei upgrades.

After the unit reboots after the upgrade I can reach the firewall until Sensei's engine starts. At that point it drops all traffic on my protected interfaces. I've been keeping an unprotected interface that I can easily swap to for these times. All I have to do to fix this is to disable "Enable engine heartbeat monitoring". Once I do packets start flowing again and I can re enable it without issue. I'll pull the worker logs and send them to you if that helps.

14

Sensei / Re: Sensei on OPNsense - Application based filtering

« on: July 10, 2019, 10:48:28 am »

Hi @donatom3,

Many thanks for the heads-up.

Reading https://forum.opnsense.org/index.php?topic=13436.msg61861#new, I'm guessing this is related to global netmap buffer size. Looks like something changed with the new netmap.

Can you try setting hw.igb.rxd and hw.igb.txd to 1024 and see if that helps.

This is the setting which is working for us for 19.7.r1

If this works, then we'll need to calculate & adjust dev.netmap.buf_num to accommodate 4096 rx/tx descriptors.

MB,

Looks like Franco saw my post and sees that a merge for the ring size didn't make it to the 19.7 netmap kernel.

https://forum.opnsense.org/index.php?topic=13436.msg61879#msg61879

He says he'll have it fixed by release.

For now I've dropped my hw.igb.rxd and txd to 1024 rebooted and it's working. Just need to remember to switch back once they fix it.

15

19.7 Legacy Series / Re: Sensei and Suricata not seeing interfaces on RC1

« on: July 10, 2019, 10:46:29 am »

Nice catch, ring size is still too small on stock FreeBSD.

We have the patch on versions up to 19.1, but had to revert for merging newer netmap code in 19.7 and it wasn't applied on top again.

https://github.com/opnsense/src/commit/815f865ea29c

Will be fixed in 19.7 release. Thanks!

Cheers,
Franco

Thanks I got it going for now by just dropping my tuneables a bit

Set them to below
hw.igb.rxd 1024
hw.igb.txd 1024
net.link.ifqmaxlen 2048

Both services are working. I'll change them back once 19.7 releases.