Menu

Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Show posts Menu

Messages - binaryanomaly

#61
Documentation never hurts. An intuitive, fail-safe UI is king though ;-)
#62
QuoteDid you hit apply on the main alias configuration page after editing the alias?

Obviously not. I did not see the apply button and the notification at all as it was outside visible screen area.

So there's nothing lacking from a functional perspective it's more a usability / UI thing.
#63
A minor thing I observed and thought I'd report:

Current behavior
If you change an alias that is in use with a firewall rule, nothing happens and the change is not applied to the fw rule set.

Desired behavior
A change of an alias that is in use by a fw rule should trigger the fw rule reload notification so the users are aware that the change is not applied immediately and requires a reload of the ruleset.

#64
OK, it seems that

proto actually is the "ip protocol number" in the ipx header field (https://en.wikipedia.org/wiki/IPv4#Header).

Therefore the translation table here can be used:
https://en.wikipedia.org/wiki/List_of_IP_protocol_numbers

#65
Hi,

In the live log I see that a connection gets blocked:

proto 0
protoname ip


Now I want to create a rule that allows this.
But I have no "ip" only protocol I could select nor a number "0" in the rule creation UI.

How can one translate the protocol mentioned in the log to the ones available for the rules?

Edit: As it does not appear in the logs atm it seems that my guess for IPV6-ICMP may have been right - but how could I determine without guessing?
#66
Zenarmor (Sensei) / Re: 10.0.0.1 Top remote host
June 02, 2021, 08:34:21 PM
Quote from: mb on June 02, 2021, 05:22:46 PM
This would behave like a "default" setting?

I'd assume so.

For the majority of the users the (snippet of) "local" traffic is likely not of significant interest in the reports. So it can probably be disabled by default.
#67
Quote from: rudiservo on June 01, 2021, 02:59:10 PM
use policy instead of adding rules ajustments.

This is very IMPORTANT.

I made the mistake in the past as well and this makes your opnsense config xml file explode. This has the negative side effect that it slows down almost everything even pure UI interactions and generates high CPU load.

If you have a lot of rule adjustments it's quite annoying to clean it out. For me it worked best to export the config, remove the rule adjusments manually from the config xml and re-import it.

#68
Zenarmor (Sensei) / Re: 10.0.0.1 Top remote host
June 02, 2021, 06:15:04 AM
Quote from: mb on June 02, 2021, 01:26:23 AM
For local connections where both the originator and the destination is in your local networks, destination will be like regarded as a remote host, since in Sensei terminology one end needs to be "remote".

Hmm I do understand that this is the way your tool internally works. But would ague that the common understanding is the opposite and that these are NOT remote hosts by the very definition: https://datatracker.ietf.org/doc/html/rfc1918#section-3

Quote from: mb on June 02, 2021, 01:26:23 AM
You can filter out these though. Just enable "Hide local connections" under Report Settings (right top corner).

Thanks, I was looking for a setting like that and couldn't find one.

(I would naturally rather have it expected in Settings -> Reportig & Data though as almost anything else reporting related is there.)
#69
Zenarmor (Sensei) / 10.0.0.1 Top remote host
June 01, 2021, 10:35:54 PM
Why does sensei think 10.0.0.1 is the top remote host?

It's the OPNsense LAN interface IP, gateway, local DNS resolver and very obviously not a remote host?
#70
Thanks for your thoughts Thomas.

Using capital letters as a prefix seems like a good idea.

From my past experience aliases can grow quite quickly because of the numerous ports you need to open for quite some services. Using aliases makes it very simple to add/remove ports quickly from my experience.

As for firewall rules your right it's the description only. I found that a meaningful description helps me to identify the desired rules after some time much quicker than if have to look at every one in detail to identify the required one. But that's just my personal experience/preference.

This helps to keep it simple and efficient from my point of view.

I had 1:1 interface groups in the past. While it wasn't particular helpful until I changed NICs once it also wasn't really additional effort. Just want to understand if this is recommended as general best practice of abstraction similar to aliases.
#71
As I'm just in progress of setting up everything from scratch again I am thinking about how to name the aliases and firewall rules best in order to have an efficient and self-explainable standard.

What is the alias and firewall rule naming scheme you guys use and why?

For aliases I'm thinking of something like


[Domain]_[Asset type]_[Name]

Domain = net, web, com, p2p, media, ...
Asset type = ip, network, port, ...
Name = Service or App name


and use nesting wherever it makes sense.

For rules I'm thinking of


[Origin] to [Target] [Service or App] [allow/deny]


Does this make sense?
Would you recommend something else, why?

Bonus question: Would you recommend using interface groups even if there's only 1 interface?
#72
Well, I can live with ~3 Gbps that's not really an issue  ;)

Nevertheless the drop in performance is significant and probably not without impact on weaker hardware. Also it would allow to waste less resources in virtualization scenarios, generate less heat, etc., etc.

I have a 11th Gen Intel(R) Core(TM) i5-11600 @ 2.80GHz at work here, 4 cores for OPNsense, somewhat doubt that it is the bottleneck. On the other hand it seems to be somewhat stuck around 2.7/8 Gbps also with the previous hardware.
#73
Quote from: sy on May 21, 2021, 07:25:02 PM
Hi,

The bypass will provide us the info that slowness is due to engine or netmap. In Bypass mode, Sensei just forward the packets. If the results are the same in bypass mode, we should check the netmap side.

Ok thanks, I understand.

The results are almost identical in bypass mode:


    Latency:     2.79 ms   (0.23 ms jitter)
   Download:  2705.55 Mbps (data used: 2.6 GB)
     Upload:  1146.04 Mbps (data used: 1.2 GB)
#74
Quote from: sy on May 20, 2021, 07:50:32 PM
Hi,

Did you try Sensei in bypass mode?

No, stopped the engine completely.
Why should I test in bypass mode? I either would want it off completely or fully functional.
#75
Ok, understood.

For home users such as myself efficiency and simplicity of configuration is certainly of importance in addition to flexibility.

I'm not even sure if I'll need traffic shaping and prioritization in my setup at all as bandwidth and latency have never been an issue so far.