Messages

Figured it out.

This is actually how the API seems to work.
You can toggle rules on/off with: /api/filter/toggleRule/{uuid}/0 or 1

But this does not apply the change to the pf.
To achieve this one must: /api/filter/apply


Thought I'd post it here in case someone stumbles over this as well.

Hi

I'm using filter automation, and while the toggle command seems to be executed, the rule doesn't seem to be really taken into use.
Version: OPNsense 25.1.5_5

Steps:
1, activate rule via API (interface based rule)
2, test rule -> not working
3, check rule is active in the GUI -> yes
4, search the rule in statistics/rules -> rule cannot be found
5, hit Apply button in Automation/Filter without changing anything else and test rule -> now it works
6, search the rule in statistics/rules -> now rule can be found

Anyone else noticed this or using filter automation successfully?

Cheers
Christian

[also needs the right "GUI: All pages"]

Thanks Franco for the clarification.

Also feedback from my side (not knowing if this is a bug and how to raise one).

What really got me off track is:
A user that shall be allowed SSH and has a shell assigned also needs the right "GUI: All pages"

So it seems impossible to add users with only SSH access at the moment.
Not sure if this works as designed or not?

ty
Christian

Hi

I'm trying to create a user which has SSH login rights.

From https://docs.opnsense.org/manual/how-tos/user-local.html I know I should set that right via a group or directly on the user itself under "Effective Priviliges" by assigning "User - System - Shell account access"

But I'm missing that item. There are no "User -" items like in the screenshot in the Link obove.


I only see access rights for GUI I could assign (see attachment).



Am I blind? Or is there something else to be done?

ty,
Christian

igb0 itself is not configured as an Interface.

This might be the problem

Assign igb0 without ipv4 or ipv6 settings.

I guess then the GUI settings will work

cheers
Christian

Do you use bridges?
If so FreeBSD 13 has improvements there

Ok,
lacking the skills to really follow @ocochards benches I chose to do what he calls "drunk method".
I tried out random things.

In the end I reinstalled the box with OPNSense 22.1 and rebuilt the config today.
What can I say... performance is back.

Thanks to FreeBSD 13 I even can use bridges to transfer SMB ~50 to 75 MB/sec. now

I suspect some tunables carried over from 21.7 might have caused my issues, but this is only a wild guess.


Just wanted to let the internet know what solved the problem for me.

Cheers
Christian

[No changes were made to any config.]

Hi

This is the topology:

  .-----+------.
  |  O   igb0  +
  |  P            |              .------------.     .------------.
  |  N   igb1  +--Trunk--+ Switch    +- -+ RPi        |
  |  s            |              .------------.     .------------.
  |  e   igb2  +
  |  n            |             .------------.
  |  s   igb3  +----------+ Laptop    |
  |  e            |             .------------.
  .------------.

RPi is connected to an access port in VLAN10
Laptop is connected to default LAN interface on OPNSense (no VLAN)

igb1 is connected to a trunk port, native VLAN10 and some other ones tagged.
(i know it might be better to change to everything tagged, I planned to do that in 22.1)


Before Upgrading I performed iperf3 tests and got throughputs ~900MBit
After Upgrading the same test shows ~300MBit
No changes were made to any config.

I have read through some articles of https://github.com/ocochard
There I also found the bridge performace issue in FreeBSD12 which was one of the reasons to update OPNSense to 22.1.

Question:
How to debug where this bottleneck resides (I'm very sure it is inside the OPNSense box)?
What board tools of OPNSense / FreeBSD13 can you recommend to look at?

I suspect it has to do with Queues/number of CPUs bound to the interface/interrupts/whatever?


Cheers
Christian

Ok,
verstehe deinen Ansatz, welcher auch über die Firewall Regeln umgesetzt werden kann, solange man die Domains kennt.

Nur ist es über den Proxy weit treffsicherer als über Domainlisten in der Firewall.
Sobald große Provider mit vielen (dynamisch wechselnden) IPs hinter einer Domain und CDN involviert sind wirds mit der Firewall schwierig.
Netflix und Amazon Prime zB

Aber dir hilft der Proxy in deinem Fall denke ich nix.
Der supportet nur http und https

Denke nicht, nein.

Alle Domains in den nas_allow sind whitelisted für den Host nas
Der Rest geht ja sowieso nicht durch.

D.h. ich steuere pro Host/Hostgruppe die erreichbaren Domains.
Wenn der böse smartTV dann was anderes als Netflix versucht (zB über hbbtv eine Reichweitenmessung des Senders den ich gerade schaue), dann hat er Pech gehabt.

Der Vorteil ist eben die Steuerbarkeit pro Host.
Ich fange Werbung, Malware etc. über Pihole ab, steuere dann aber hier noch für bestimmte Hosts wo die hin dürfen.

Gibt es keine acl für einen Host der in der Firewall über den Proxy darf, dann kann der überall hin.

Einfach mal für einen Host ausprobieren - wenns nicht passt löscht man die Files wieder und fertig.

Hi

Yes, the NAT rules that redirect to the proxy

Hallo

Ich habe eine ähnliche Anforderung gehabt.
Ich wollte steuern können, auf welche Domains der smartTV surfen darf und auf welche nicht.
Also ein Whitelisting von Domänen pro Client/Clientgruppe.

Ich bin zum Schluss gekommen dies über IP und Firewall zu lösen ist zu aufwändig und zu ungenau.
Mit der ganzen Cloudinfrastruktur und der verschlüsselten Kommunikation wird immer irgend eine IP in der Liste fehlen und irgendwas nicht funktionieren.

Darum verwende ich jetzt den Proxy transparent mit Custom ACLs.
Diese müssen aber am CLI von OPNsense eingestellt werden.
SSL no bump sites habe ich im GUI "." drin, somit wird SSL auch nirgends aufgebrochen.

Schau mal da:
https://forum.opnsense.org/index.php?topic=21730.msg102455#msg102455

lg
Christian

Yes

Hi

2 thoughts:

1, wired is on a different subnet and you are not repeating mdns between subnets
-> MDNS repeater must be installed in that case

2, the ports needed for Airplay are blocked by the firewall
-) filtering bridge might be enabled in case you use a bridge interface
-) if wired is on a different subnet then you must allow Airplay ports to be routed

br
Christian

Hi

Why not include !NoDSTProxy on the first rule as well?

br
Christian