Sensei on OPNsense - Application based filtering

[mb]

Hi @nines, thanks for letting us know. Yes, we did not have reports for vmx up until now.

Can you send a PR? We want to have a closer look.

[nines]

Hi @mb

yes of course. like described here: https://help.sunnyvalley.io/hc/en-us/articles/360045745053-Reporting-a-bug

?

[mb]

yes of course. like described here: https://help.sunnyvalley.io/hc/en-us/articles/360045745053-Reporting-a-bug

Yep.

[nines]

Hi @nines, thanks for letting us know. Yes, we did not have reports for vmx up until now.

Can you send a PR? We want to have a closer look.

unfortunately I cant, the vm instantly reboots after the update
any ideas?

[mb]

Try this:

Before the upgrade make sure you have autostart disabled for Sensei: Sensei -> Status -> Set "Start on Boot" to Disabled.

Also make sure that you don't have Suricata enabled.

Upgrade the system, and before starting Sensei/Suricata send the PR.

[GreenMatter]

I've got exactly the same - after upgrading my OPNsense VM to 20.7 Sensei had ceased to run. Due to constant reboot loop, I had to restore VM snapshot and now I'm back on 20.1.9 - I reported a bug as well.
Are you going to improve compatibility for vmx drivers?

[sorano]

So I had sensei running on 20.7 using the vmx0_vlan## interfaces.

So I started playing around, switched to just using vmx0 interface together with vlan id's in sensei and got my host in a crash bootloop without a snapshot  ::) . Is there anyway to disable sensei during boot?

[nines]

Try this:

Before the upgrade make sure you have autostart disabled for Sensei: Sensei -> Status -> Set "Start on Boot" to Disabled.

Also make sure that you don't have Suricata enabled.

Upgrade the system, and before starting Sensei/Suricata send the PR.

that worked, report sent!

[sorano]

Is there anyway to disable sensei during boot?

Well, I answered my own question:

Boot up in single user mode
Mount the fs
/usr/local/etc/rc.d/eastpect disable

[mb]

Hi @sorano,

Your message just landed while I was preparing my post. Nicely done. Thanks for the update.

Upon user reports received, we've just updated the latest netmap status. Please see below post before you update to 20.7:

https://www.sunnyvalley.io/post/status-on-the-netmap-improvement-efforts-for-opnsense-20-7/

For the problematic drivers, work has already begun. I'll provide interim updates on their status.

[mb]

Friends who use OPNsense on ESX:

Which ESX version are you on?  We would like to know about the problematic versions.

[sorano]

Friends who use OPNsense on ESX:

Which ESX version are you on?  We would like to know about the problematic versions.

This is my setup:

Hypervisor: VMware ESXi, 7.0.0, 16324942
VM Compatibility: ESXi 7.0 and later (VM version 17)
Distributed switch version:   7.0.0
Distributed Port group: Vlan trunk (Tagging vlans inside OPNsense)

Distributed Port group Security Policies:
Promiscuous mode   Reject ( I'm running Native MAC Learning instead to work around the vswitch + CARP duplicates issue)
MAC address changes   Accept
Forged transmits   Accept

Like I wrote earlier; Running Sensei on the interfaces that are tagged in OPNsense (vmx0_vlan#) works, but running on the "native" vmx0 interface + vlan id in sensei will cause kernel race.

[Waschl]

Friends who use OPNsense on ESX:

Which ESX version are you on?  We would like to know about the problematic versions.

Hello. I have the same problem. My setup:
Hypervisor: VMware ESXi 6.7.0 Update 3 Build 16316930
VM Compatibiltiy: 6.7 U2
Standard vSwitch

Running OPNsense with no special interfaces configurations (VLAN etc.) using vmxnet3.

[scream]

Running into the same issue as well: https://forum.opnsense.org/index.php?topic=18338.0

Code Select Expand


Hypervisor: VMware ESXi, 7.0.0, 16324942
VM compatibility: 6.7 U2


OPNSense VM having 7 vmx interfaces. I use VLAN in my networks but I do tagging on ESX dvSwitch so OPNSense isn't aware of VLANs. Just seeing vmx0 - vmx6 interfaces.

Reverted to snapshots of 20.1.9 I created before upgrade.

[mb]

Ok, I think this vmx bug has been resolved on FreeBSD 12-STABLE:

https://svnweb.freebsd.org/base?view=revision&revision=363163

Let's do some tests.