Messages

Yes, rule id now seem to have differing formats. It messed up my graylog parsing for a while. I am not sure what led to the decision for mixing UUID style. It would be better if they were consistent IMO. In the meantime ;-) are you able to modify the grok expression to cater for both formats?

Are the listed defaults those of the kernel or are they opnsense config defaults?

It seems inconsistent IMO but in firewall rules, an explicit port range is entered with a dash rather than a colon (in port aliases). The help states "Destination port number or well known name (imap, imaps, http, https, ...), for ranges use a dash".

So the Gigaset is creating a SIP INVITE packet, then refusing to send it because it exceeds 1300B and aborts the call?
Looking at the packet captures I made, when experiencing VoIP problems (long story also involving a Gigaset VoIP DECT phone), the biggest SIP packet size I saw was 1269B. That too was the SIP INVITE with authorization header.
@lmoore's suggestion to disable, say, some codecs to reduce the SIP payload may be enough. Other than an outgoing permit rule, I doubt firewall/NAT comes in to play this early in the call. Good luck!

yes, looking at the txt files it makes sense. First call ist 401, 2nd gives the 200 ok.

I'm confused now. Does this not suggest a SIP INVITE was successfully sent?
EDIT ah as @lmoore pointed out, they are responses to SIP REGISTER.

When I dial a number I get error 401.

My VoIP experience is limited to my home setup but IME I always see a 401 response to the initial SIP INVITE of an outgoing call. Then, there comes a second INVITE containing the Authorization Digest, after which the call proceeds successfully.

I don't see a "static port" option on the new Source NAT interface

I was wondering the same. There is the 'Translate Source Port' field. Maybe setting this to the same port/alias as 'Source port', equates to static port mapping?

AIUI It needs to be sent as a POST request, with uuid as part of the json payload.

I'd used the above, or something similar, with both pfSense and OPNsense. Having just posted and then upgraded to 26.1, I see the uuid format has changed for some rules. So I switched to using the API to get the uuid/label mappings. All works well as does 26.1.1 in general.
Thanks all.

Based on that, I think the Monit tests above are not reliable as I've observed the UUIDs on my system changed over time.  It seems the rule label is the best way to track the rule, but those aren't present in /var/log/filter/latest.log.

True, the exported filter logs don't include the textual description either, only the uuid. So, if you use an external log aggregator, you will need some form of mapping. I've used elasticsearch directly and later graylog and any lookup table needs to be updated if you modify the firewall rules. Graylog for example, can automatically detect when a static lookup table (CSV file) has been updated. So I run a script to pull the new rules and generate a new CSV.

Code Select Expand

echo '"key","value"'
(ssh root@${opnsense} cat /tmp/rules.debug | egrep -o '(\w{32}).*' | sed -r 's/([[:alnum:]]{32})(" # : |" # )(.*)/"\1","\3"/g' | sort -t, -u -k1.1)

Which produces something like

Code Select Expand

"key","value"
"000c1faaa3005e1ce16fc687337a7b7b","Default deny / state violation rule"
...


So all rules (floating, group, interface) come before the NAT rules at the end of the ruleset.

Thanks @Monviech. I am still exploring but I think I will stick with the Manual option in that case. The other benefit being the rule is visible in the edit pane.

I upgraded to 26.1. Both the upgrade and rule export/import went without a hitch.

Following the upgrade, all the NAT rules had been switched to 'Manual'. My previously linked NAT fw rules were successfully imported along with everything else. I then disabled all the old rules.

I tried switching some destination NAT rules to the 'Register rule' option. The resulting rules (quick) are visible under the new rules Inspect pane, at the bottom of the list.
Do they therefore run after all other quick rules and before all non-quick rules?

I take your point. If on the other hand you have only known ASNs or subnets that you wish to allow, Pass would seem OK. But I am now feeling cautious about mixing Pass forward rules with those requiring explicit filter rules. It starts to feel messy.

That leaves the question in which situations the "Pass" mechanism might be useful at all.

AISI pass may be useful when:
- source/destination criteria in the port forward rule will serve all needed filtering criteria.
- no egress filtering is needed.
- no tagging, policy routing, traffic shaping (or something else?) is needed.

Would that be about right?

@meyergru I have a couple of portforwards on the WAN where the pass action won't be satisfactory. However I also have some on the WAN and almost all those on the local interfaces, where I think it will be appropriate. Just that it never occurred to me use that option in the past and so I have, what I now think, may be redundant filtering.

EDIT Having said that, it may get confusing in the future having the cause of passed traffic not visible in the filter list. I'm sure that would catch me out especially with my memory these days. In fact I think this is a good enough reason for me not to use Pass and instead explicitly define filter rules to pass port forwards.

Thanks all for the pass clarification. That makes it clear and makes sense. I have been aware of the packet processing order but somehow got misled ;-)

If the source/destination criteria on the forwarding rule are sufficiently selective, then I suppose a 'pass' action is sufficient. In fact it now occurs to me that some of my associated rules may be redundant.

This thread has proven very helpful in understanding the new UI and its implications. Thanks to all the contributors! I haven't upgraded to 26.1 yet but have found the automation filters inspect UI pleasant to use and insightful.
My current set up has some single interface floating rules (mostly WAN). Some are artifacts of a migration from pfsense/pfblocker where the auto-generated rules were floating with direction 'both'. Considering those, alongside my other existing rules, there is actually no need (either for priority or for bi-directional reasons) for them to be defined as floating. So I have now moved all single interface floating rules to their respective interfaces and ordered things appropriately.

For me, the only headache might be maintaining filter rules for port-forwards. I use these on internal interfaces as well as WAN. I'd considered changing my port forwards to pass. However AIUI from posts elsewhere on the forum, the new system may impact the way some have used the 'pass' option on port forwards. Or am I misunderstanding?