Messages

The FreeBSD port of PF however does not have NAT64 support AFAIK, because it was forked before NAT64 support was added.
PFSense seems to have gotten native support for NAT64 recently, but I do not know how it is implemented there.

Native NAT64 - by the keyword 'af-to' - was introduced with FreeBSD 15[1].

The question came up before on the forum but I can't find it right now. The gist is: OPNsense will adopt FreeBSD 15.1, timeline Mid to End 2026, if I remember correctly (or Dec 2026 - Mid 2027?).

Btw, apalrd has taken over Tayga[2] and is pushing it further but I'm not sure if his/their effort is Linux only. In the video I think is only Linux mentioned.

[1]https://man.freebsd.org/cgi/man.cgi?query=pf.conf&manpath=FreeBSD+15.0-RELEASE
[2]https://github.com/apalrd/tayga
[3]https://www.youtube.com/watch?v=WlQH8KubgiA

I'm still not sure how well this will work though since the filter log directory can contain >30GB of files.

What behaviour would you expect from an application in such an situation? Many apps just freeze or crash :)

Personally I would try to evaluate if the app can handle it and if not show a pop-up. Either abort with that pop-up so that the user can select less files. Or fallback to load only what you can load and let the user know what was loaded and what not.

Although the fallback is probably not a good idea since the user had an idea what she wanted to look through and then wouldn't be sure what is included and what not. It is probably better to let the user know and abort so she knows that it will require two steps to look through all files.

I've thought about this, and the main issue is sorting the entries since I can't load everything into memory. ... I need a reliable way to order them, and using file names/creation times isn't reliable because users can rename/move files.

Wouldn't it be enough to read the first and the last line(s) of a file, determine the time stamps of these entries and you'd know the order of the files?

Should be even faster now with v0.4.0.

It certainly feels faster. And in general I very much admire the fact that you update the application and the documentation!

One way to improve it could be to skip the loading screen and go straight to the TUI, with indexing happening in the background. The advantage of this would be that the TUI opens instantly, and while some features might not be available right away, most users probably wouldn't even notice this since indexing is quick.

It would be helpful if it could read multiple file or a directory and then it may become more of an issue.

You got time until someone presses <Enter> in a filter field :)

Another option, at least in theory, would be to skip building the index altogether and just process everything on the fly. We could cache the lines we've already interacted with to avoid doing the same thing over and over again. However, I'm not sure how well this would perform on low spec devices.

That would need some testing, I assume that it will be very slow with lots of data. It would not only depend on the CPU/RAM specs but also on the read speed of the disk.

Does that answer your question?

Mmmh, can you login to OPNsense and do a "host one.one.one.one" or something similar?

DNS, it's always DNS ;)

Code Select Expand

Fetching changelog information, please wait... fetch: https://pkg.opnsense.org/FreeBSD:14:amd64/25.7/sets/changelog.txz: Host does not resolveThe router can't resolve pkg.opnsense.org. Can you resolve anything else from the OPNsense?

Let's call this the worst OPNsense bug of 2025 that never happened.

Like a quote out of a action movie :)

Very nice, thank you for confirming first. If it's not easily reproducible it would be quite hard to track.

I opened GH issue DEV 26.1.a_621: deleting one firewall rule => all rules disappear.

It's reproducable for me by creating a new VM from the 25.7.r1 ISO and upgrading to Development 26.1.a_621 (which is only two steps, 1) upgrade pkg and 2) upgraded directly to 26.1.a_621).

The config.xml attached in the issue (and we track the issue there, I assume)

I have never heard of this behavior before, it is quite strange. Are you confident it is a bug and can be reproduced?

If yes can you open a github ticket, and also share the config.xml file that you used?

Thank you Cedrik, in the current configuration I can reproduce it, yes. But I'll reset the config and try to replicate it with a minimal configuration. If it still does happen, I'll open a GH ticket and add the config.xml to the ticket.

Otherwise I'll have to dig deep :).

Do you already have "Destination NAT" instead of "Port Forward" under NAT?

No, it is still called 'Port Forward', of which I have two + an Outbound NAT for IPv6.

Addition: Deleting one of the port forward rules make them all (two) disappear). In that use case there is again a <rule>...</rule> added. <rule> after </outbound> and </rule> before </nat>. Removing them resolves it.

Answering myself: After diff-ing the two configs, there is an extra <rule> ... </rule> in the config file.

Right after </nat><filter> there is the wrongly added '<rule>' and before <scrubs> is the surplus closing </rule>.
Manually removing these two lines made the rules appear again in the GUI.

Does OPNsense get a fixed IP, 192.168.100.101 or is dynamic? Did you disable NAT on OPNsense?

Next step would be Diagnostics > Packet Capture on WAN for ICMP or TCP/22 or TCP/443 and try to access it from 'Internal Network'.

The rules do look absolutely OK. I assume you did press 'Apply changes'?

Good Morning,

On a OPNsense lab instance, I'm on latest DEV 26.1.a_621-amd64 and created a rule on WAN for ping. Afterwards I deleted that rule and boom, all firewall rules were gone, on all interfaces. That was ... surprising :). The firewall rules were created in the standard 'Rules', not 'Rules [new]'

That instance runs on Proxmox (which runs on a Hetzner root server) and has three virtual interfaces and Tayga: WAN (vtnet0), LAN (vtnet1), TEST (vtnet2) & Tayga.

If I delete one/any rule on WAN, LAN or TEST, all firewall rules on all four interfaces disappear in the GUI (also on Tayga). On interface Tayga deleting a rule does work normally.

In the config file the rules are present and do work, would indicate a GUI issue.

Is that something anyone else encountered? I can share the working and non-working config.

Adding, modifing, enabling/disabling rules does also work correctly.

Can you show the rules you created on the OPNsense WAN interface? Access and ping to the WAN should work when you create a rule on WAN. Usually something like (leave default whats not mentioned):

# for SSH and HTTPS
pass, interface WAN, protocol TCP, destination 'This Firewall', destination ports 22,443.

# for Ping
pass, interface WAN, protocol ICMP, destination 'This Firewall'

You can set 'ICMP Type' to 'Echo Request' if you want to restrict what ICMP querys can be send.


Also disable 'block bogons networks' and 'block private networks' on WAN.