Hi,
I have a strange issue since the upgrade to 25.7.3_3.
On a wireguard interface, an existing rule with an alias in the source address field doesn't work anymore. If I put "Any" instead of the alias, the rule works again (even if it's not what I want ^^ ).
Do I miss a breaking change ?
Hi,
If you had 25.7.3 and grabbed 25.7.3 did you also hit "apply" under firewall: aliases?
And which alias type would that be exactly that doesn't work?
Cheers,
Franco
Hi,
I just did it, and unfortunately, it still doesn't work.
Aliases types are all "Hosts" in my case.
And a packet trace or firewall log shows that the packets in question really match the source address in the alias?
Yes it matches the alias, sorry I should mention it
Here is the content of the capture (nc -v 192.168.1.8 22 from 192.168.21.4 ) :
length 64: (tos 0x0, ttl 64, id 19606, offset 0, flags [DF], proto TCP (6), length 60)
192.168.21.4.60366 > 192.168.1.8.22: Flags , cksum 0x5721 (correct), seq 840528611, win 65424, options [mss 1392,sackOK,TS val 3660705569 ecr 0,nop,wscale 7], length 0
Ok, then please show the rule definition.
I think I see why it doesn't work, in Diagnotistics/ Aliases, the alias I try to use is empty, whatever I do (I tried to change the content, Hit the apply button), the table is still empty
Then show the alias definition in the UI.
I don't know if it's a coincidence, but it seems that all my aliases that contains two underscore in the name are empty. Others seems to be fine.
Finally it seems to be random ( I have more than 100 aliases )
> don't know if it's a coincidence, but it seems that all my aliases that contains two underscore in the name are empty.
This is odd, because 25.7.3_3 fixes exactly this.
Cheers,
Franco
Searching in the logs, I found this :
[ba512d3a-0fe9-4e3b-8872-24a007932bed] Script action failed with Command '/usr/local/bin/flock -n -E 0 -o /tmp/filter_update_tables.lock /usr/local/opnsense/scripts/filter/update_tables.py ' returned non-zero exit status 1. at Traceback (most recent call last): File "/usr/local/opnsense/service/modules/actions/script_output.py", line 78, in execute subprocess.run(script_command, env=self.config_environment, shell=True, File "/usr/local/lib/python3.11/subprocess.py", line 571, in run raise CalledProcessError(retcode, process.args, subprocess.CalledProcessError: Command '/usr/local/bin/flock -n -E 0 -o /tmp/filter_update_tables.lock /usr/local/opnsense/scripts/filter/update_tables.py ' returned non-zero exit status 1.
Ok, what happens when you manually run "/usr/local/opnsense/scripts/filter/update_tables.py" then?
this appens:
The error was self-explained, I don't know why, after the update in System/Settings/General, dns servers list was empty ( it was not the case before).
My issue is resolved :)
For information, I have a 2 nodes cluster in HA, and the same thing happens on the second node.
I had to change the configuration this way to make it works again.
i'm quite sure that it was not needed before the update ( My dns server is adguard running locally on opnsense).
Moreover, without adding 127.0.0.1 as a nameserver, I had dns resolution from the cli, but not from the gui
Quote from: rarcel on September 10, 2025, 04:28:31 PMMoreover, without adding 127.0.0.1 as a nameserver, I had dns resolution from the cli, but not from the gui
do you have in one of your alias the "content" populated with nameserver in letter ? example (site.com)
if yes which "type" of alias is ? (url or host/s)
if it is url try to change to host/s
Can you try this patch?
# opnsense-patch https://github.com/opnsense/core/commit/0425834f9
Still investigating why this changed, a bit short on time this evening so far.
Cheers,
Franco
Nobody?
Cheers,
Franco
Quote from: franco on September 11, 2025, 07:14:58 AMNobody?
Cheers,
Franco
tried, but i cannot recreate the error (also reverting the configuration of the aliases before the last change).
The bug appears to have been added 7 years ago. May have explained a few unclear cases in the past. I think what 25.7.3 has done is invalidate the cached alias and caused the bug to happen. Personally, I'm very glad it was reported and fixed.
It obviously goes without saying that host aliases with no way to resolve them are a problematic combination that can come back at any time and cause indeterministic results (at least from the top).
Thanks,
Franco
Quote from: franco on September 11, 2025, 11:46:33 AMThe bug appears to have been added 7 years ago. May have explained a few unclear cases in the past. I think what 25.7.3 has done is invalidate the cached alias and caused the bug to happen. Personally, I'm very glad it was reported and fixed.
It obviously goes without saying that host aliases with no way to resolve them are a problematic combination that can come back at any time and cause indeterministic results (at least from the top).
Thanks,
Franco
👍
thank you for yor time and work!
Sorry for the late answer.
I cannot reproduce what I had yesterday by removing the dns server.
I can only tell you that I applied the patch after failing to reproduce, and it doesn't break anything on my installation
Quote from: franco on September 11, 2025, 07:14:58 AMNobody?
Cheers,
Franco
Franco,
Sorry wasn't able to break the network again before calling it a night. People get upset during TV time. Anyways, I updated to _7, changed the alias back to URL vice Host, flushed the alias via diagnostics and it refreshed correctly pulling the information. I'll watch the logs on it and let you know if it doesn't hold.
Thanks for correcting the problem.