Messages

Can you send a bug report by selecting all checkboxes? It is the upper right corner of Sensei GUI.

Done. Thanks  :)

Hey @mb. Any suggestions or help on this one?

I'd like to upgrade to the Premium version, but really need a working install before I can do that  :)
thanks.

Have played around with this a little more and have now enabled TLS Encryption and HTTPS with ElasticSearch, refreshed the Sensei config but same results - the wizard went through fine, but checking the DB URL connection, it errors with:

Code Select Expand

Elastic Search Database (https.//search.domain.co.9200) cannot be reached

I did generate a self-signed certificate, no password, etc.

Testing from the shell works okay:

Code Select Expand

curl --user elastic:elastic123 --insecure -X GET "https://search.domain.co:9200/?pretty"
{
  "name" : "server1.cloudapp.azure.com",
  "cluster_name" : "elasticsearch",
  "cluster_uuid" : "some-random-string",
  "version" : {
    "number" : "7.9.2",
    "build_flavor" : "default",
    "build_type" : "deb",
    "build_hash" : "some-random-string",
    "build_date" : "2020-09-23T00:45:33.626720Z",
    "build_snapshot" : false,
    "lucene_version" : "8.6.2",
    "minimum_wire_compatibility_version" : "6.8.0",
    "minimum_index_compatibility_version" : "6.0.0-beta1"
  },

[http]

Hi,

Need some help please with external Elasticsearch  :)

I've been playing around with using a remote Elasticsearch instance in Azure, on an Ubuntu VM. A while back I had this working okay, although not secured (it was connecting to the ES instance over http://azure_ip:9200).
Then something broke, which was fine as it made me look at securing it properly ;)

So, it seemed that one way to secure this was to configure SSL on the Elasticsearch installation with Nginx reverse proxy - which I did, and that appeared to work:

Code Select Expand

❯ curl -u elastic:changeme -kL https://search.domain.co
{
  "name" : "server1.cloudapp.azure.com",
  "cluster_name" : "elasticsearch",
  "cluster_uuid" : "some-random-string",
  "version" : {
    "number" : "7.9.2",
    "build_flavor" : "default",
    "build_type" : "deb",
    "build_hash" : "some-random-string",
    "build_date" : "2020-09-23T00:45:33.626720Z",
    "build_snapshot" : false,
    "lucene_version" : "8.6.2",
    "minimum_wire_compatibility_version" : "6.8.0",
    "minimum_index_compatibility_version" : "6.0.0-beta1"
  },
  "tagline" : "You Know, for Search"
}

Then, I tried setting up Sensei with a fresh config and deleted the '/usr/local/sensei/etc/.configdone' file.

During the setup wizard, it complained about the Database URL as just:

Code Select Expand

https://search.domain.co
So, adding the URL as

Code Select Expand

https://search.domain.co:443 seemed to work and i could complete the setup.

But, I then click on Dashboard and get the error:

Code Select Expand

Elasticsearch service is not running!
In order to view reports, you need to start Elasticsearch service.

Checking the Sensei config and resetting the DB url, it now errors with:

Code Select Expand

Elastic Search Database (https.//search.domain.co.443) cannot be reached. Please check your network connectivity and make sure the remote database is up and running.

But, running the test curl cmd from the opnsense shell works okay.

Any ideas on this error.
Or what's the recommended way to setup a secure, external ES instance ?

Thanks  ;D

Hi, I'm having a problem with Multi WAN failover not, well, failing over  ;D

Setup:
2x DSL lines
2x WAN interfaces (1 for each DSL!)
ONsense: 20.1.3

For a while I just used them as separate gateways, routing certain VLAN traffic out of the 2nd gateway by using the 'Gateway' option in the firewall rule.

Due to regular, short(ish) outages on one of the DSL lines, I thought I'd try Multi-WAN failover and see if that reduced the impact of the outages.

So, I followed the OPNSense documentation for Multi-WAN failover and the base setup worked.

Then, today I had a short drop on the DSL ... and lost Internet until it came back online. WAN failover didn't appear to work.

I then tested it out - and pulled the main DSL line from the socket. Same thing ... no failover. I lost Internet traffic untilI'd plugged the DSL cable back in and the line came up.

Some observations during the "outage":

- packet loss went to 100% in about 1 minute on the primary (downed) gateway
- in the log, it showed an error on the monitor IP: dpinger: WAN_PPPOE 8.8.8.8: sendto error: 65
- "Gateway > Single":
  - Primary WAN gateway got auto-marked as Disabled, priority: defunct; 100% packet loss; and got removed from gateway dashboard widget
  - WAN2 interface is showing active (default route)
- Gateway Group status shows correctly: the tier 2 GW active
- DNS was resolving okay for Internet domains
- But, no ping/traceroute, internet access, etc

Any suggestions on what I can look at ?

I'm not convinced that the

load_dn_aqm dn_aqm PIE loaded

message that's the last thing on the console is the issue - this message appears related to the Shaper config I have setup.

If I disable the Scheduler config, then this message doesn't appear, but the console now just stops at another line.
However:
- Connecting via serial console is fine - I get to a login prompt
- I can connect to the GUI, all is working fine

So, I'll let it run and see if I get any real problems :)

Squid proxy maybe? IPFW (as in shaper or captive portal) has been know to block squid start.

I'm not running squid. It's a fresh install - no plugins, but with my config loaded.

So, installed fresh image of 20.1 and initially it looked okay - booted fine and I could configure an IP, etc.

Restored a config file to it, and now when rebooting  (or power off/on), the console output (VGA) gets "stuck" at the same place -

Code Select Expand

load_dn_aqm dn_aqm PIE loaded

However, I can still reach the LAN interface okay, log in okay, etc.

Not sure why the console boot output is not completing fully ???

FYI - same issue here on 19.7.x - has been running fine for months. Had to powerdown/boot the box and it never came back online.

Plugged in a monitor, last line on screen:

Code Select Expand

load_dn_aqm dn_aqm PIE loaded

Will try a re-install...

Not wanting to hijack someone's thread, especially whilst fixing the problem is still in progress...

But I'm interested to see how this works out. I've just installed Maltrail and also getting no events showing in the GUI (but it's only been running ~20 minutes, so will wait a while longer ;)

Update on my install...

I still didn't see any events for a while.
I had the Monitor Interface set to listen on a 'trunk' interface (i.e. the interface has no native vlan).
I changed this to listen on a particular vlan interface (i.e. local network), pinged the 'bad IP' and the event showed up in Maltrain GUI straight away  :)
Will continue to monitor.

Not wanting to hijack someone's thread, especially whilst fixing the problem is still in progress...

But I'm interested to see how this works out. I've just installed Maltrail and also getting no events showing in the GUI (but it's only been running ~20 minutes, so will wait a while longer ;)

But it is currently causing problems and if my firewall doesn't work properly after a restart, I have no choice but to uninstall sensei.

I had a similar problem - my LAN interface was unreachable after a reboot of the OPNsense box, so no Internet access.
Uninstalling Sensei fixed the problem.

On this thread, I was advised:

Don't use tagged and untagged packet on the same interface with Sensei

Which is what I had - a native (untagged) VLAN on the same interface as a trunk (tagging a few other VLANs).
I have now added another interface - a trunk with no native VLAN, and tagging all VLANs on that interface.
But, I have not re-installed Sensei yet - just waiting as there seem a few install issues still. Once these are sorted, I will install and try again.

There is no one. It's from BSD. Don't use tagged and untagged packet on the same interface with Sensei. Try it and give feedback, please...

Working on it. Have the trunk now setup (had some interesting times trying to get it to work with my unifi switch/APs, but have now simplified my overly complex config, hopefully).

Just making some final tweaks and then I'll look at re-installing Sensei and see how it goes.

If you have free port enable it without set an IP on it and name it TRUNK :) After this assign the VLANS on it. Not on the LAN port.

I do have a spare interface. So, you mean add a new interface (label TRUNK, no IP), then move the existing VLANs onto the new trunk interface ? Assume I'll also have to tag the previous default VLAN now.

Is that the preferred way to configure VLANs - I couldn't see a guide for this ?

I've had an on-going issue with my OPNsense box, which I believe Sensei is the culprit. Having uninstalled it, all seems fine. Here's the rundown:

- Bought new QOTOM hardware (primarily to try out Sensei - having run OPNsense successfully for some time on an APU2C4 box)
- Setup QOTOM box, and installed Sensei
- Have a few VLANs configured, so set the main LAN interface (igb0) as the Sensei protected interface
- Additionally, configured a new WAN interface (attached to a 2nd DSL line - but not using failover, etc. Just routing some traffic out an alternate WAN link)

Then, a problem started whenever the OPNsense box rebooted. Initially, this was just during an upgrade but for troubleshooting I also rebooted it.

The issue was that the LAN interface was no longer reachable, so no internet connection for any hosts on any VLAN.
Using the serial console connection on the box, from a shell i could ping outbound (both gateways), but could not ping any internal hosts. No igb0 traffic was being routed.

Rebooted again this morning (due to an error with Sensei reports not showing), and the same thing. After a 'reload services' (serial console option 11?) - some traffic on the default VLAN was working okay. But other VLANs were not.

I then noticed in the DHCP server log that discover packets from clients that were supposed to be on the 'other' VLANs was showing up on the default VLAN, and the DHCP server was offering IPs from the default VLAN (no subsequent DHCP requests were showing up though). Why would traffic from other VLANs be showing up on the default VLAN ???

3 main things had changed since the issues started: 1. new hardware, 2. installed Sensei, 3. Added new WAN interface

So, first off I uninstalled Sensei, rebooted ... and all was working with no issues.
Rebooted again, still working.

For now, it seems Sensei was the problem. No idea what it was doing to my VLAN traffic.