Messages

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?

One rule performs the NAT and the second permits the resulting traffic. With the previous system, it was a NAT port forward rule and a (potentially auto-managed) firewall rule.

I have not tried 26.1RC yet. But I have a feeling, with the way I've set up NAT and FW under 25.7, a straight forward migration will not be possible. For example, the change in the priority of floating rules on single interfaces and the lack of auto/associated firewall rules for port forwards.

I've bound (binded?) an openvpn server instance to 127.0.0.1 and port forwarded the relevant interface.

LE certificates are to be reduced to 45 days in 2028. But there is also a new DNS challenge planned that will be based on a persistent DNS record.

This gave me a new kind of error: A 403 "User account ID doesn't match account ID in authorization" and recreated my token with Zone Zone Edit and Zone DNS Read permissions. I removed "CF Account ID" from Services -> ACME Client -> Challenge Types, and now only use

- CF API Token
- CF Zone ID (Optional)

It works again.

When I set up opnsense letsencrypt to use the cloudflare DNS-01 challenge I also found I had to omit the CF account ID in order for it to succeed.

@OPNenthu Wow. I redact my post and hope the OP comes back to see your solution. Thanks.