Sensei on OPNsense - Application based filtering

[manjeet]

Thanks @MB for the update. Looking forward to it.

Also, Yesterday i enabled the email reporting and today i got this message "Scheduled reports could not be generated. Probably elasticsearch service is not running or not working properly. Please check elasticsearch service manually."

Elastic search is working fine, reports in dashboard and reports section looks all good. Do not understand what could be the issue..

[mb]

Hi @manjeet,

We're having a look at Scheduled Reports now, let's also check this.

[the-mk]

@mb: when I look to the reporting mail - how is that number of "unique local hosts" of the "quick facts" derived? I do not have that many hosts in my network...

[N0_Klu3]

So would this work at replacing pfblockerng?
As in AD Blocking?

Also I read stuff about VLANs, basically I have 2 VLANs running on my main LAN Ethernet port.
Would Sensei work?

I'm planning on rebuilding to OPNSense hopefully today, but I'd really like some sort of ad blocking to replace pfblockerng.

[mb]

Hi @the-mk,

Do you see different statistics in the UI, or are they the same?

If they are: we saw this happen when Sensei was being run for a WAN interface. In that, LAN/WAN directions are being reversed for Sensei. So you see remote host count in place of locals and vice versa.

If not, let's have a look if we're missing something.


Hi @N0_Klu3,

You can try for yourself. It's easy to try out Sensei.

Yep, if you just add the parent LAN interface to the protected interfaces, than you're good to go.

[N0_Klu3]

@mb do you still need an invite or install link?

[mb]

Hi @N0_Klu3,

You can use this command to install 0.8:

curl https://updates.sunnyvalley.io/getsensei8 | sh

[Space]

Hi,

are these files needed? Took most of my disk space ...

Code Select Expand

root@OPNvirt:/usr/local/sensei/log # du -sm * | sort -n
1 active
14156 archive

These logs contain statistics for all interfaces per second ... but I did not find an option to disable these logs ...

Thanks and best regards,

    Space

[malac]

@manjeet,

This is addressed via policy based filtering coming up with Premium subscription. Details almost complete. Hope to announce it very soon.

@malac,

Please send your public IP address to sensei - at - sunnyvalley.io. We'll run a trace.

Have you found something?

[mb]

are these files needed? Took most of my disk space ...
These logs contain statistics for all interfaces per second ... but I did not find an option to disable these logs ...

Hi @Space,

Within this beta period, in times of troubleshooting, they can be very valuable for us to point out the location of some of the problems.

Nearing 1.0, we'll cease  to archive logs. In the meantime, adding a functionality to automatically purge logs older than 10 days.

Thanks for pointing this out.

[mb]

Have you found something?

Hi @malac,

Yep, it looks like engine is still a little bit too sensitive for response times. We've lowered the thresholds a bit. Coming with beta10.

[the-mk]

Hi @the-mk,

Do you see different statistics in the UI, or are they the same?

If they are: we saw this happen when Sensei was being run for a WAN interface. In that, LAN/WAN directions are being reversed for Sensei. So you see remote host count in place of locals and vice versa.

If not, let's have a look if we're missing something.

when comparing the quick facts from the last report mail with the conns facts from the dashboard - they are pretty much the same when having the report interval set 05/18/2019 00:00 to 05/19/2019 00:00.
I'd expect that the number of unique local hosts are about the same numbers as IP-addresses are listed in the table of local assets from the dashboard.
protected interfaces on the firewall in question with sensei 0.7.0 are 6 vmx-network cards to different LANs and one vmx to WAN.
but maybe my understanding if unique local hosts is wrong here?
could it be that i.e. a host talking on the network of interface #1 is talking to another host on the network interface #2 and the same source hosts also talks to the internet (WAN)?

[mb]

Hi @the-mk,

Thank you very much for providing additional information.

Whether we decide if some IP address is local or remote depends on the flow direction.

A little bit of background info how Sensei works & decides the flow direction:

Sensei deploys between the ethernet adapter and the host operating system, bridging the two, forwarding packets back and forth, and at the same time doing the inspection. Typically we are deployed on inner-facing interfaces.

It assumes that ethernet side of the bridge is LAN and Operating System side is WAN. So flows initiated from the LAN side is considered they are egress, and flows which are initiated from the WAN side are ingress.

For eggress connections, the source IP address who initiated the connection is tagged as "Local", whereas for ingress connections, it's the destination IP address.

So, in your scenario, I'd expect that you having a protected interface on the WAN side might complicate things, since this time sensei will regard all outgoing connections as Ingress (for that interface) and regard the remote IP addresses as local.

Might worth removing that interface from protected interfaces and try to see if this changes things.

If that's not the case, please let us know so that we can have a look at it together.

[kaviraj]

Hello,

Been testing sensei 0.8.0.beta9 since some days now and since yesterday am facing some strange problems. Some clients are unable to resolve DNS. If i change the client IP everything start to work again. I tried to uninstall and reinstall but still the same.

OPNsense is running over virtualised environment (Proxmox) with kernel 19.1.4 having netmap support as am using virtio.

Test case:
1. I have a client with IP 10.249.10.228/24. When i run a dig it returns a timed-out. A tcpdump on the hypervisor shows that the request was forwarded over the OPNsense interface but a dump on OPNsense interface shows nothing.

2. I stop sensei engine dig starts to work. But as soon as i start it, the client is unable to resolve DNS.

3. Same client but i change IP to 10.249.10.11/24. Dig works.

I may provide remote access if needed.

Thanks for your help.

[mb]

Hi @kaviraj,

Many thanks for reaching out. Please watch for 0.8.0.beta10 which will be coming out today. We have a fix for this.