Sensei on OPNsense - Application based filtering

[mb]

if you really want to do that and really do it, some users would be very grateful to you. Me too of course! ;-)

How can I or how can others keep an eye on the development of this feature?
Is there a kind of roadmap or something similar?

Hi René,

We will do it You're all welcome.

To keep up with the development, roadmap etc, best is to keep following this forum thread and also following company web site and twitter account:

https://twitter.com/sunnyvalley

Beginning April, we'll share more information about the upcoming feature set and more about the technology.

For now, I can tell that the technology at the heart of Sensei is a powerful packet analysis engine which is aimed at providing contextual network visibility, protection at all ports for all devices and also protection against encrypted threats which are gaining momentum.

Utilizing this core tech, our mission is to provide enterprise grade cyber protection for everyone, let it be a household, a small business or an enterprise with thousands of users.

From this perspective, making Sensei run on any scale is our priority.

 

[donatom3]

And you start working on getting it to run on lower end machines after I order the new qotom case with 6 built in intel nics and a lga 1151 slot for 6th of 7th gen core desktop processors.

It's the Qotom Q600G6 for anyone interested.
https://www.aliexpress.com/item/Qotom-DIY-Powerful-Firewall-Router-Appliance-Q600G6-Barebone-System-Support-6th-7th-Gen-Processor-DDR4-RAM/32967092263.html?spm=a2g0s.9042311.0.0.154d4c4d2CNERH

[manjeet]

HI, I Can not open report in either Dashboard or Reports giving me an error "An error occurred while report is being loaded!".

In view error message it says:
{
  "error": {
    "root_cause": [],
    "type": "search_phase_execution_exception",
    "reason": "all shards failed",
    "phase": "query",
    "grouped": true,
    "failed_shards": []
  },
  "status": 503
}

Both "Sensei Packet Engine" and "Elasticsearch" are running. I have restarted the system and error is still there.

[mb]

Hi manjeet,

Thanks for reporting this. Are you on 0.7?

We've got two more reports for the same problem and currently investigating it.

We'd like to dig deeper. Can you share your relevant elasticsearch.log ( located at /var/log/elasticsearch/ ) through sensei - at - sunnyvalley.io ?

For a workaround, you can run these two commands to reset the indexes: (beware: this will erase your reporting history)

/usr/local/sensei/scripts/installers/elasticsearch/delete_all.py
/usr/local/sensei/scripts/installers/elasticsearch/create_indices.py

Let us know if this does not fix the problem.

[ltb76]

Hi,

I'm new to OPNsense and Sensei, testing it to replace my soon expering PaloAlto home firewall.

Just did a default install and it seems to be working well (I see several blocked add sites under "Blocked Sites Explorer").
I might be missing something though. I tried adding "Bing" under "App Controls" - however I can still access bing.com. (I then tried adding Facebook - and that blocks Facebook). might the "bing" app be broken or am I missing something?

Another question, I looked in the manual but did not find the answer. Initially I added all my interfaces (WAN, LAN, LAN2 and DMZ) under "Protected Interfaces". dooing that seems to block DNS.
With the WAN interface protected, DNS trafic seems to be blocked with "Network Management category is administratively restricted" - even if does not appear to be blocked under "App Controls". Should I only add "LAN" interfaces to "protected"?

Is there a way to "not protect" an IP on a protected interface? Lets asume I have a device / client on the LAN interface that I for some reasone want to bypass all checks - is that posible?

I'm running
Sensei: 0.8.0.beta4
OPNsense: 19.1.4
Running ontop of VMware, 4 vCPU (D1540), 12GB RAM, vmxnet3 NICs

[hbc]

Should I only add "LAN" interfaces to "protected"?

AFAIK Sunnyvalley recommends not to block WAN and use suricata for this instead.

Is there a way to "not protect" an IP on a protected interface?

Not in the free version. That is a feature of the premium edition.

[manjeet]

Thanks @MB. This fixed the issue.

I am currently running 0.7 & I am sending you the email for logs and screen shot error.

[BeNe]

I have a question about the VLAN feature.
I use some VLAN on OPNSense and added all my interfaces to the "protected interfaces".
After that all connected VM´s inside the VLAN´s are offline and unable to access the opnsense (which means they are offline for all networks)

If i remove the "LAN" interface from the "protected interfaces" which is my physical interface,
the access from the VM´s inside the VLAN´s is ok again.
I have clients connected to "LAN" as well and would like to protect them, too.

Here is a overview:

LAN (em0) is my physical device and all VLAN are added to this interface:

Code: [Select]

10_DMZ (em0_vlan10) -> v4: 172.16.10.254/24
                    v6/t6: 2003:f2:63c9:63e1:4c1f:32ff:fe6d:4ae/64
 20_VPN (em0_vlan20) -> v4: 172.16.20.254/24
 30_Pentest (em0_vlan30) -> v4: 172.16.30.254/24
                    v6/t6: 2003:f2:63c9:63e3:4c1f:32ff:fe6d:4ae/64
 40_WifiGuest (em0_vlan40) -> v4: 172.16.40.254/24
                    v6/t6: 2003:f2:63c9:63e4:4c1f:32ff:fe6d:4ae/64
 50_IoT (em0_vlan50) -> v4: 172.16.50.254/24
                    v6/t6: 2003:f2:63c9:63e5:4c1f:32ff:fe6d:4ae/64
 60_Dev (em0_vlan60) -> v4: 172.16.60.254/24
                    v6/t6: 2003:f2:63c9:63e6:4c1f:32ff:fe6d:4ae/64
 70_WiFi (em0_vlan70) -> v4: 172.16.70.254/24
                    v6/t6: 2003:f2:63c9:63e7:4c1f:32ff:fe6d:4ae/64
 80_Server (em0_vlan80) -> v4: 172.16.80.254/24
                    v6/t6: 2003:f2:63c9:63e8:4c1f:32ff:fe6d:4ae/64
 90_Clients (em0_vlan90) -> v4: 172.16.90.254/24
                    v6/t6: 2003:f2:63c9:63e9:4c1f:32ff:fe6d:4ae/64
 LAN (em0)       -> v4: 172.16.17.254/24
                    v6/t6: 2003:f2:63c9:63e0:4c1f:32ff:fe6d:4ae/64
 PIA_VPN (ovpnc1) -> v4: 10.56.10.6/32
 WAN (igb0)      -> v4: 192.168.217.2/24
                    v6/DHCP6: 2003:f2:63c9:6300:6eb3:11ff:fe1b:aedf/64


I´m on Sensei 0.8.0.beta4 and OPNsense 19.4.1

Do you need some more informations ?
Thank you!

[mb]

Hi BeNe,

We're aware of this issue. There's another Sensei deployment exactly the same setting with yours and experiencing the same problem.

Looks like something weird with em-vlan-netmap trio. We're on this. Will update the thread when it's done.

One question: are you fine when you remove the trunk interface and just protect vlan child interfaces?

[BeNe]

Hi mb,

thanks for that fast information.

Yes, if i remove the trunk Interface (LAN em0 in my case) from the protected interfaces list, the machines inside the VLAN 's are reachable again.

Gesendet von meinem Pixel 2 mit Tapatalk

[mb]

Hi Bene,

All welcome. Thanks for the information. Can I ask a favor? Can you try the new netmap kernel to see if your current setup works? (child interfaces protected, trunk not protected).

Here's how to do it:

https://forum.opnsense.org/index.php?topic=11477.msg55261#msg55261

[BeNe]

Hello Murat,

of course  But the problem is still the same. I installed the new Kernel:

Code: [Select]

# uname -a
FreeBSD surtur.my-network.de 11.2-RELEASE-p9-HBSD FreeBSD 11.2-RELEASE-p9-HBSD  4ea457eb7b8(master)  amd64
If i add "LAN (em0)" to the protected interfaces, the VLAN´s are offline.
So revert back to the stock kernel. Added a screenshot from my OPNsense Console after adding the interface.

[mb]

Hi Bene,

Messages in the screenshot are ok: netmap telling you it was able to open the ethernet port.

I can confirm that there's something weird with the trunk interface when we bridge hw <-> sw rings. After a while packet transmission stalls for the child interfaces:

Code: [Select]

658.955704 [2909] netmap_transmit           igb3 from_host, drop packet size 541392904 > 2048
683.531482 [2909] netmap_transmit           igb3 from_host, drop packet size 541392904 > 2048

Looking into that.

For now our advise is - if you're using VLANs -:

• Stay with the stock kernel which comes default with the OPNsense release, we need more work in new kernel with regard to VLANs
• Do not put any untagged traffic to your VLAN trunk port and you should be able to protect vlan child interfaces just fine

Our plan is to be able to process the trunk interface directly and for all VLANs and you'll not need to separately select child interfaces. Will get you updated on this.

For now, if you can carve out the untagged traffic from the trunk port, you're ok.

[mb]

Dear Sensei users,

An update on broken Elasticsearch indices:

After digging together with users who have reported the issue, it looks like the indices were broken because some index file integrity got broken.

This is usually because of abrupt shutdown of the firewall. If power goes off suddenly, before Elastic does a full write of its in-memory buffers, than we have a broken index.

So, not to experience this issue try to turn off your system gracefully.

If in any case this happens, Sensei 0.8.0.beta6 has a "Fix Elastic indices" button under Sensei -> Configuration -> Reporting & Data menu. Just click on the button and Sensei will reset only the broken indices.

0.8.0.beta6 is available for update for 0.8 users.

0.8 looks stable enough to offer as an update for existing 0.7 installations. If we do not see any outstanding issues, we'll move 0.8 to the general repo in a few days.

[donatom3]

MB,

I'm using dhcpv6 with track interface. Anytime Sensei starts after a reboot or an upgrade my ipv6 stops working until I do a release and renew of the entire WAN interface. It just did it to me again on the beta 6 upgrade.

Code: [Select]

Mar 22 18:13:25 opnsense: /usr/local/etc/rc.newwanipv6: Dynamic DNS: updatedns() starting
Mar 22 18:13:25 opnsense: /usr/local/etc/rc.newwanip: ROUTING: skipping IPv6 default route
Mar 22 18:13:25 opnsense: /usr/local/etc/rc.newwanip: ROUTING: skipping IPv4 default route
Mar 22 18:13:25 opnsense: /usr/local/etc/rc.newwanip: ROUTING: no IPv6 default gateway set, assuming wan
Mar 22 18:13:25 opnsense: /usr/local/etc/rc.newwanip: ROUTING: IPv4 default gateway set to wan
Mar 22 18:13:25 opnsense: /usr/local/etc/rc.newwanip: ROUTING: entering configure using 'opt4'
Mar 22 18:13:25 opnsense: /usr/local/etc/rc.newwanip: On (IP address: X.X.X.X) (interface: XXXXX[opt4]) (real interface: ovpnc2).
Mar 22 18:13:25 opnsense: /usr/local/etc/rc.newwanip: IP renewal is starting on 'ovpnc2'
Mar 22 18:13:25 kernel: ovpnc2: link state changed to UP
Mar 22 18:13:24 opnsense: /usr/local/etc/rc.newwanipv6: Dynamic DNS: (Success) X.X.X updated to X.X.X.X
Mar 22 18:13:24 opnsense: /usr/local/etc/rc.newwanipv6: Dynamic DNS: updating cache file /var/cache/dyndns_wan_X.X.X_0.cache: X.X.X.X
Mar 22 18:13:21 kernel: ovpnc2: link state changed to DOWN
Mar 22 18:13:21 opnsense: /usr/local/etc/rc.newwanipv6: Resyncing OpenVPN instances for interface WAN.

Code: [Select]

Mar 22 18:15:55 dhcp6c: dhcp6c REQUEST on igb0 - running newipv6
Mar 22 18:15:55 dhcp6c[89888]: add an address 2605:X:X:36:1de7:22c5:7284:90a5/128 on igb0
Mar 22 18:15:55 dhcp6c[89888]: add an address 2605:X:X:a900:4262:31ff:fe00:7873/64 on igb1
Mar 22 18:15:55 dhcp6c[89888]: add an address 2605:X:X:a9ec:4262:31ff:fe00:7874/64 on igb2_vlan55
Mar 22 18:15:55 dhcp6c[89888]: add an address 2605:X:X:a9ef:4262:31ff:fe00:7874/64 on igb2_vlan200
Mar 22 18:15:55 dhcp6c[89888]: Received REPLY for REQUEST
Mar 22 18:15:55 dhcp6c[89888]: Sending Request
Mar 22 18:15:55 dhcp6c[89888]: Sending Solicit
Mar 22 18:15:54 opnsense: /usr/local/etc/rc.linkup: ROUTING: skipping IPv6 default route
Mar 22 18:15:54 opnsense: /usr/local/etc/rc.linkup: ROUTING: skipping IPv4 default route
Mar 22 18:15:54 opnsense: /usr/local/etc/rc.linkup: ROUTING: no IPv6 default gateway set, assuming wan
Mar 22 18:15:54 opnsense: /usr/local/etc/rc.linkup: ROUTING: IPv4 default gateway set to wan
Mar 22 18:15:54 opnsense: /usr/local/etc/rc.linkup: ROUTING: entering configure using 'lan'
Mar 22 18:15:54 dhcp6c[89888]: failed to remove an address on igb1: Can't assign requested address
Mar 22 18:15:54 dhcp6c[89888]: remove an address 2605:X:X:a9ec:X:31ff:fe00:7874/64 on igb2_vlan55
Mar 22 18:15:54 dhcp6c[89888]: remove an address 2605:X:X:a9ef:X:31ff:fe00:7874/64 on igb2_vlan200
Mar 22 18:15:54 dhcp6c[89888]: Sending Release
Mar 22 18:15:54 dhcp6c[89888]: Start address release
Mar 22 18:15:54 dhcp6c[89888]: remove an address 2605:X:X:X:1de7:22c5:7284:90a5/128 on igb0
Mar 22 18:15:54 dhcp6c[89888]: Sending Release
Mar 22 18:15:54 dhcp6c[89888]: Start address release
Mar 22 18:15:54 dhcp6c[89888]: restarting
Mar 22 18:15:54 opnsense: /usr/local/etc/rc.linkup: HOTPLUG: Configuring interface lan
Mar 22 18:15:54 opnsense: /usr/local/etc/rc.linkup: DEVD Ethernet attached event for lan
Mar 22 18:15:54 kernel: igb1: link state changed to UP
Mar 22 18:15:50 opnsense: /usr/local/etc/rc.linkup: DEVD Ethernet detached event for lan
Mar 22 18:15:50 eastpect[42809]: nm2::igb1^: permanently promiscuous mode enabled
Mar 22 18:15:50 eastpect[42809]: nm1::igb1:1: permanently promiscuous mode enabled
Mar 22 18:15:50 kernel: 750.076995 [2219] netmap_ioctl got 10000 extra buffers
Mar 22 18:15:50 kernel: 750.069849 [ 736] netmap_extra_alloc allocate buffer 24583 -> 24582
Mar 22 18:15:50 kernel: 750.062915 [ 736] netmap_extra_alloc allocate buffer 24582 -> 24581
Mar 22 18:15:50 kernel: 750.055985 [ 736] netmap_extra_alloc allocate buffer 24581 -> 24580
Mar 22 18:15:50 eastpect[42809]: nm0::igb1:0: permanently promiscuous mode enabled
Mar 22 18:15:50 kernel: 750.049074 [ 736] netmap_extra_alloc allocate buffer 24580 -> 24579
Mar 22 18:15:50 kernel: 750.042410 [ 736] netmap_extra_alloc allocate buffer 24579 -> 0
Mar 22 18:15:50 sshlockout[10974]: sshlockout/webConfigurator v3.0 starting up
Mar 22 18:15:50 kernel: 750.035617 [2216] netmap_ioctl requested 10000 extra buffers
Mar 22 18:15:50 kernel: igb1: link state changed to DOWN
Mar 22 18:14:06 dhcp6c[89888]: no responses were received
Mar 22 18:14:06 dhcp6c[89888]: no responses were received
Mar 22 18:14:04 dhcp6c[89888]: no responses were received
Mar 22 18:14:03 dhcp6c[89888]: no responses were received
Mar 22 18:13:49 dhcp6c[89888]: Sending Release
Mar 22 18:13:49 dhcp6c[89888]: Sending Release
Mar 22 18:13:48 dhcp6c[89888]: Sending Release
Mar 22 18:13:48 dhcp6c[89888]: Sending Release
Mar 22 18:13:41 dhcp6c[89888]: Sending Release
Mar 22 18:13:41 dhcp6c[89888]: Sending Release
Mar 22 18:13:40 dhcp6c[89888]: Sending Release
Mar 22 18:13:40 dhcp6c[89888]: Sending Release
Mar 22 18:13:37 dhcp6c[89888]: Sending Release
Mar 22 18:13:37 dhcp6c[89888]: Sending Release
Mar 22 18:13:37 dhcp6c[89888]: Sending Release
Mar 22 18:13:37 dhcp6c[89888]: Sending Release