Messages

Hello,

I remember that previous releases had a test button for sftp uploads under ACME Client -> Automations.
Under 21.7.6 this button is missing on my system. Is this a bug or a feature?

Thanks
Beclar

I am not quite sure why we need sensei to monitor the wireguard interface in Wireguard Road Warriors setup? as in this setup the wireguard interface just act like your WAN, where sensei is a lan packet filter/report tool?

if we really want to secure the wireguard interface, shall we not use opnsense IDS? thanks

Another use case for Sensei: Securing/filtering/logging of road warrior devices, e.g. smartphones of the kids outside the local wlan (using mobile data or public wlans). With my setup above  Sensei controls the traffic of these devices the same way if they are connected at home via wlan or on the road via wireguard.

Edit: Oh yes, that's  the scenario described by MB. :)

Thank you very much for your support!

Latest patch gives a nice layout in 100 % view on my little laptop. I noticed some lines that are only on the (old) left part of the controls, but not on the new template controls. See attached screenshot.

opnsense-patch -a kulikov-a 030815a
looks more correct to me. although still not very pretty

Indeed... with this patch the layout in any zoom factor prevents overlapping and therefore non-functional control buttons. But: on my laptop the >>-Button, the drop down "Choose template" and the trashbin are now three lines (in 100 % view). Nevermind, it seems only a cosmetic problem.

No errors are shown in console :-(

Problem of "dead" + button only occurs when + and >> buttons are touching each other. I tested this with Chrome Windows . On my laptop Chrome´s 100 % zoom stucks the two buttons together which results in the dead + button. See attached screenshot of 100 % zoom - apart from the fact that the buttons are not inline.

If I decrease the browser zoom factor the two buttons are seperated and work without any problem.

It is clickable for me, but only on the left hand side of the + box. So not broken, but also not 100%

Tried again on Google Chrome (Windows): It works with 90 % zoom factor, where the "+" box is far away from the ">>" box (see attached screenshot "working").
The + box is NOT working on my laptop when the "+" box touches the ">>" box which is on 100 % zoom factor in Google Chrome (see attached screenshot "not_working").

Hi folks,

I am wondering if 21.1.6 broke Firewall Live Log filtering? The update adds a new template feature but the "+"-button (for adding filter criterias such as "action contains blocks") is not clickable anymore...

Thanks
Beclar

Hi folks,

has anyone tried to set up Adguard WebGUI using https with the same cert that OPNsense´s WebGUI uses?

Thank you very much
Beclar

Just a little follow up for the records:

At the moment it seems that we have two options to let Sensei monitor/control Wireguard Road Warriors: Switch back to wireguard-go in OPNsense (= not using wireguard-kmod) or set up a dedicated Wireguard router (separate from OPNsense) and bridge it to an separate interface in OPNsense.

I tried the second approach on an Proxmox Host and it is working fine: Virtualized OPNSense has now a separate "normal" virtual NIC for Wireguard-Traffic. An Archlinux-VM with Wireguard kernel support (part of the recent Archlinux kernel) is managing all Wireguard connections (with port forward from WAN to the Wireguard listening port). The VM forwards all traffic from the clients to the Wireguard subnet via OPNSense´s virtual Wireguard NIC.

Both virtual NICs  (OPNSense and Archlinux-VM) are bridged on the Proxmox Host. 

With this setting all traffic vom Wireguard Road Warriors is routed through the Wireguard-NIC in OPNSense and can be monitored / controlled by Sensei (the Wireguard-NIC in the OPNSense-VM is considered as a "normal" virtual NIC).

Okay, this is no quick & dirty workaround (especially not quick). And of course only easy to set up with virtual machines where you can simply add virtual NICs etc. On the other side you can separate the Wireguard tunnel handling from OPNSense and may choose your preferred WG implementation (with the extra effort of maintaining one more VM).

Ui, that is a bad regression for everyone who likes to enjoy the speed of wireguard kmod in combination with the ease of Sensei.

Let's hope the devs will soon find a solution.

Best regards
Beclar

Hi all,

I am quite new to Sensei and it looks very promising so far!

But I have a problem with the protection of Wireguard Interfaces: The Sensei engine doesn´t recognize any traffic on the Wireguard Interfaces (here wg0 und wg1). They can be activated as "Protected Interfaces" and they are shown unter Sensei - Status - Network Interfaces.

But all traffic counters of the wg-Interfaces rest at 0 and reports dont mention any Wireguard related activity.

I am on OPNsense 21.1.4 using wireguard-kmod (NOT wireguard-go userspace). Sensei Engine is 1.8.2, Routed Mode (L3 Mode, Reporting + Blocking) with native netmap driver.

Any hints what could be wrong?

Thank you very much in advance,
Beclar

die Gateway Groups ziehen ohnehin nur, wenn sie in den FW-Rules gesetzt sind.
Ansonsten funktioniert dein Szenario wie gewünscht (betreibe ich ähnlich), so lange du nur IPv4 intern verwendest.

Super, vielen Dank für die Bestätigung, dass ein Multiwan Failover quasi Out of the Box funktioniert, wenn ,,Allow default gateway switching" aktiviert ist. Aus dem offiziellen Wiki zum Multiwan ist das für mich nicht so klar hervorgegangen. Eine Gateway Group mit entsprechendem Route Policying braucht man dann wohl nicht einzurichten, wenn es nur darum geht, im Falle eines Gateway Ausfalls sämtlichen Traffic über eine andere Upstream Leitung zu schicken.

Guten Morgen,

ich bin Homeschooling- und Homeoffice-geplagter Familienvater und habe eine Verständnisfrage zur Einrichtung von Multi-WAN (unsere Internet-Anbindung soll redundant laufen, vorhanden sind Kabel-Internet und als Failover-Backup eine LTE/G5-Anbindung über einen LTE-Router).

Konkret: Braucht man für ein simples Failover zwischen zwei WAN-Upstream-Gateways eine Gateway-Group? Reicht es nicht aus, wenn man den Upstream-Gateways unterschiedliche  Priority-Werte zuweist (niedriger = bevorzugt bei der Auswahl als Default-Gateway) und unter Settings - General die Option "Allow default gateway switching" aktiviert? Nach meinen Verständnis müsste das Default-Gateway dann bei einem Ausfall automatisch auf das andere Upstream-Gateway gesetzt werden.

Meine Ausgangslage: Zwei WAN-Anschlüsse (Kabel und LTE-Router) = zwei separate Upstream-Gateways, für die ein Failover eingerichtet werden soll. Wenn der Kabelanschluss ausfällt, soll sämtlicher ausgehender Traffic über den LTE-Router geleitet werden. Wenn der Kabelanschluss wieder läuft (Gateway Monitoring geht wieder auf online), soll dieser wieder als Default Upstream genutzt werden.

Für beide WAN-Anschlüsse ist jeweils ein Upstream-Gateway eingerichtet, und zwar für Kabel-WAN mit einer Priorität von 254 (niedriger = bevorzugter bei der Auswahl als Default-Gateway) und für das LTE-WAN mit 255 (höher = nachrangig gegenüber Kabel-WAN bei der Auswahl als Default-Gateway). Außerdem ist "Allow default gateway switching" aktiviert.

Das offizielle Tutorial empfiehlt für ein Multiwan-Failover die Einrichtung einer Gateway-Group mit unterschiedlicher Gewichtung der Upstream-Gateways als Tier 1, Tier 2 und die Anpassung der Firewall-Rules, damit der Traffic über die Gateway-Group gelenkt wird.

Ist das überhaupt nötig? Oder kann man für ein bloßes Failover-Setup nicht die Firewall-Rules so belassen, dass jeweils das Default Gateway (also *) genutzt wird? Denn eigentlich müsste doch schon über die Option "Allow default gateway switching" das Default Upstream-Gateway passend gesetzt werden, wenn es bei zwei Upstream-Gateways zu einem Ausfall kommt. Die Auswahl des jeweiligen Upstream-GW als Default sollte doch über den Priority-Wert automatisch erfolgen (ähnlich Tier 1 und Tier 2 bei einer Gateway-Group)?

Falls sich zufällig jemand damit näher auskennt, würde ich mich über eine kurze Klarstellung freuen. Möchte mich vor einer Umkonfiguration erst informieren (planloses Ausprobieren ist derzeit schwierig, weil der Familienrat derzeit sehr empfindlich reagiert, wenn es dadurch zu Ausfällen kommt... )

Vielen Dank,
G.

Is this problem already fixed? If so, in which release (or is it necessary to apply a patch manually)?

I noticed I did something wrong because dnscrypt-proxy does not start after reboot. I must type in "service dnscrypt-proxy start" in the shell. Not sure what I did wrong. lol

/etc/rc.conf is root:wheel and not executable (I think that is correct)

If anybody else knows let me know :-) I may just use a cron job @reboot because my skills are poor.

Cake, did you read this post?