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 - Jackknife4782

#1
General Discussion / Re: Native NAT64 support
February 05, 2026, 01:32:33 PM
If I WiFi call out, I can't receive any calls back unless I wait a few minutes. Had a couple people call me and their calls failed if it was still within a few minutes of my WiFi call out. After a few minutes I can receive WiFi calls again.

Edit:  Ok I found something odd...When I call my wifi phone from outside the network it connects.  If I try to call the same wifi phone again right away it does not connect.  However, if I call another number first with the outside phone and then call the wifi phone again, it connects.  Seems this could be a carrier problem and not opnsense.
#2
General Discussion / Re: Native NAT64 support
February 05, 2026, 03:58:07 AM
I updated to 26.1.1 and tried WiFi calling.  I can call out with my iPhone 15 and my Pixel 9, but neither one can receive with WiFi calling turned on. In fact the phone doing the calling does not even ring. Just goes straight to voicemail. IPv6-only network using Tayga NAT64/DNS64 works great otherwise. Just can't receive WiFi calls. Anything special I should be doing with firewall to allow inbound or something?

It's not mandatory that I get WiFi calls working. Just experimenting with the new Tayga capabilities.
#3
Tutorials and FAQs / Re: Tayga firewall rule?
February 03, 2026, 01:35:20 PM
Of course.  Don't know why I didn't realize that. Thanks for the help.
#4
Tutorials and FAQs / Tayga firewall rule?
February 03, 2026, 06:05:07 AM
I am on 26.1_4 and have Tayga setup according to the NAT64 How-To in the opnsense documentation.  It works just fine, but I am not sure I have the firewall rules setup properly.  I have the anti-lockout disabled and only allow access to the opnsense web gui via my LAN. For some reason, I can still access the gui from other VLANs when Tayga is enabled.  I notice in the firewall live log that the connection is sourced from the Tayga NAT64 IPv4 pool no matter which VLAN I access the gui from.  As soon as I disable Tayga, The gui is correctly only accessible from the LAN as I would expect.  Any ideas?
#5
26.1 Series / Re: rrdtool error after upgrade to 26.1
February 03, 2026, 05:54:39 AM
Never mind.  Found the related thread, https://forum.opnsense.org/index.php?topic=50657.0 and applied the patch.  All works great now.  Thanks
#6
26.1 Series / Re: rrdtool error after upgrade to 26.1
February 03, 2026, 04:43:22 AM
Quote from: Vincent Chen on February 03, 2026, 01:38:14 AM/usr/local/opnsense/scripts/health/updaterrd.php: The command </usr/local/bin/rrdtool create '/var/db/rrd/ovpns4-traffic.rrd' --step 0 DS:'inpass:COUNTER:120:0:2500000000' DS:'outpass:COUNTER:120:0:2500000000' DS:'inblock:COUNTER:120:0:2500000000' DS:'outblock:COUNTER:120:0:2500000000' DS:'inpass6:COUNTER:120:0:2500000000' DS:'outpass6:COUNTER:120:0:2500000000' DS:'inblock6:COUNTER:120:0:2500000000' DS:'outblock6:COUNTER:120:0:2500000000' RRA:'AVERAGE:0.5:1:1200' RRA:'AVERAGE:0.5:5:720' RRA:'AVERAGE:0.5:60:1860' RRA:'AVERAGE:0.5:1440:2284'> returned exit code 1 and the output was "ERROR: step size: value must be positive"

Also seeing system-->logs-->general filled with this error after 26.1_4.

Has something to do with Reporting.  I disabled and re-enabled local gathering of statistics and RRD graphing backend, but now In Health Reporting it says:  "Local data collection is not enabled. Enable it in Reporting Settings page".  It won't re-enable health monitoring no matter what I select in Reporting Settings.
#7
Quote from: Gary7 on August 22, 2025, 04:08:42 PMMay I ask a really "stupid" question? I haven't updated my home APU2D4 firewall, so I'm only looking at version 25.7.1_1 of OPNsense.

Are you trying to reduce the number of processes running as root?  Are you improving security by executing processes with least privilege?

If the process is not executing as root (or group wheel), the txt files in /var/db/aliastables can't be read.
I see that many of the files in /var/db/aliastables have permission "-rw-r-----  1 root wheel"

Gary

I sign in to opnsense using a non-root user as admin.  Not technical enough to answer you questions beyond that.  I just noticed the error after the upgrade and was curious if it is normal or not.  Thanks for the advice though.

Quote from: davidfi01 on August 22, 2025, 09:40:00 PM@Jackknife4782 - the checksum error results from the patch you applied. It is to be expected.

D

Ah, I understand.  Thanks
#8
Quote from: franco on August 22, 2025, 11:17:26 AMCan you try this patch?

# opnsense-patch https://github.com/opnsense/core/commit/6ee6d9d8


Cheers,
Franco

I applied the patch, but still same error after reboot.

[62298fa6-e6e7-4699-a704-987777bdd904] Script action failed with Command '/usr/local/opnsense/scripts/filter/pftablecount.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/opnsense/scripts/filter/pftablecount.py ''' returned non-zero exit status 1.

Also performed a health check and it showed a checksum error:
opnsense-25.7.2: checksum mismatch for /usr/local/opnsense/scripts/filter/pftablecount.py