"Recent posts
#1
26.7, 26.10 Series / Re: ixv virtual function inter...
Last post by teek345 - Today at 02:16:41 PMGood to know! Is your X710 setup also using VLAN tagging with SR-IOV, or are you using the virtual functions without VLANs?
#2
26.7, 26.10 Series / Re: ixv virtual function inter...
Last post by talespin - Today at 12:20:33 PMhi,
I am on 26.7 with xxv710 and using virtual functions. All working for me.
I am on 26.7 with xxv710 and using virtual functions. All working for me.
#3
Development and Code Review / Re: netflector available as pl...
Last post by franco - Today at 11:25:37 AMNice work indeed. Eventually we'll have to discuss removing older plugins (especially where upstream isn't pushing out new versions).
Thanks,
Franco
Thanks,
Franco
#4
High availability / Re: Aliases to support "No XML...
Last post by BoNetTech - Today at 10:57:37 AMThanks for the feedback, and fair point: manual creation is only a stopgap, not a real solution.
The feature request is now tracked here: https://github.com/opnsense/core/issues/11142
If you can, please add your own use case there (DC/DR pair, same alias name with different content per site, your Source NAT example with "AddOn_IP"). A concrete case from another user helps the developers judge the need.
The feature request is now tracked here: https://github.com/opnsense/core/issues/11142
If you can, please add your own use case there (DC/DR pair, same alias name with different content per site, your Source NAT example with "AddOn_IP"). A concrete case from another user helps the developers judge the need.
#5
26.7, 26.10 Series / Re: [solved] Likely messed up ...
Last post by franco - Today at 10:03:12 AMNote: you only need the legacy plugin if you do a manual rule by rule migration.
Cheers,
Franco
Cheers,
Franco
#6
26.7, 26.10 Series / Re: Upgrade from 26.7.7 to 26...
Last post by franco - Today at 10:01:11 AMYes, moving the mirror closer should help.
Cheers,
Franco
Cheers,
Franco
#7
26.7, 26.10 Series / Re: [Solved by reboot] 26.7 Up...
Last post by franco - Today at 09:58:10 AMSo -a has a history for us: https://github.com/opnsense/update/issues/90
I also don't quite get what's happening here:
Downloading kernel-26.7.8-amd64.txz with remote size 33253768:
kernel-26.7.8-amd64.txz 88% of 31 MB 691 kBps 05s
fetch: kernel-26.7.8-amd64.txz appears to be truncated: 29328007/33253768 bytes
kernel-26.7.8-amd64.txz 31 MB 634 kBps 06s
Verifying signature with trusted certificate pkg.opnsense.org.20260608... done
It's truncated and complained loudly, then soft-resumed at the end of the transfer or started anew? And then it downloads all and verifies ok? Why doesn't it work the first time? This isn't a client-side riddle IMO.
Cheers,
Franco
I also don't quite get what's happening here:
Downloading kernel-26.7.8-amd64.txz with remote size 33253768:
kernel-26.7.8-amd64.txz 88% of 31 MB 691 kBps 05s
fetch: kernel-26.7.8-amd64.txz appears to be truncated: 29328007/33253768 bytes
kernel-26.7.8-amd64.txz 31 MB 634 kBps 06s
Verifying signature with trusted certificate pkg.opnsense.org.20260608... done
It's truncated and complained loudly, then soft-resumed at the end of the transfer or started anew? And then it downloads all and verifies ok? Why doesn't it work the first time? This isn't a client-side riddle IMO.
Cheers,
Franco
#8
General Discussion / Re: Source NAT between VLANs?
Last post by steve2048 - Today at 07:12:07 AMJust a comment on this as it was giving me a fair bit of difficulty doing the same thing (basically spoofing an IP address within a particular vlan for traffic originating from another vlan). The critical thing I had missed was the source NAT has to be applied on the interface where you want the spoofed IP.
Option B: Source NAT / Outbound NAT (e.g., Hiding source IPs across VLANs)
If you need traffic leaving VLAN_10 into VLAN_20 to appear as if it originates from the OPNsense VLAN_20 interface address rather than the client's actual IP:
1. Navigate to Firewall > NAT > SourceNAT.
2. Change the mode from "Automatic Source NAT" to "Hybrid Source NAT" and click Save.
3. Click + Add to create a manual outbound rule:
• Interface: The destination VLAN interface (e.g., VLAN_20).
• TCP/IP Version: IPv4.
• Protocol: any.
• Source Address: VLAN_10 subnet (e.g., 192.168.10.0/24).
• Destination Address: VLAN_20 subnet (or any).
• NAT Address: Select Interface Address (the OPNsense IP of VLAN_20 or you can use an individual host/virtual IP if you have created one
Option B: Source NAT / Outbound NAT (e.g., Hiding source IPs across VLANs)
If you need traffic leaving VLAN_10 into VLAN_20 to appear as if it originates from the OPNsense VLAN_20 interface address rather than the client's actual IP:
1. Navigate to Firewall > NAT > SourceNAT.
2. Change the mode from "Automatic Source NAT" to "Hybrid Source NAT" and click Save.
3. Click + Add to create a manual outbound rule:
• Interface: The destination VLAN interface (e.g., VLAN_20).
• TCP/IP Version: IPv4.
• Protocol: any.
• Source Address: VLAN_10 subnet (e.g., 192.168.10.0/24).
• Destination Address: VLAN_20 subnet (or any).
• NAT Address: Select Interface Address (the OPNsense IP of VLAN_20 or you can use an individual host/virtual IP if you have created one
#9
High availability / Re: Aliases to support "No XML...
Last post by chandrayandeepak - Today at 05:32:51 AMThanks BoNetTech. Manual creation at both ends wasn't much helpful, actually.
#10
26.1, 26.4 Legacy Series / Re: Unbound reporting stop wor...
Last post by wincent - Today at 04:53:57 AMQuote from: Rick on October 30, 2026, 07:52:33 AMI'm using OPNsense 26.7.7 with py313-numpy 2.4.6_1 on a system with an AMD Athlon 64 X2 5000+ (super old, but runs OPNsense great) and noticed this yesterday when I tried to enable Unbound logging.
Apparently this error happens because recent versions of NumPy are compiled to use features on newer hardware and the complied code chokes on older hardware. (Google: numpy illegal instruction) You can see the stack trace by running "python3 -v stats.py" I tracked the error to the following dynamic-link library:
/usr/local/lib/python3.13/site-packages/numpy/_core/_multiarray_umath.cpython-313.so
I worked around this by standing up a FreeBSD 15.1 VM (on my Linux Mint system), installing Python 3.13 and building NumPy for a generic system using the following command-line, and replacing the OPNsense ".so" above with the one generated (in the same location).
python3 -m pip install numpy==2.4.6 -Csetup-args=-Dcpu-baseline="none" -Csetup-args=-Dcpu-dispatch="none"
Unbound logging is working now on my system.
Obviously this is just a workaround for the current version of NumPy.
Hope this helps.
- Rick
Great...!! Thank you, bro. I'll give it a try later :)
