"Recent posts
#1
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
#2
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.
#3
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 :)
#4
Development and Code Review / Re: netflector available as pl...
Last post by nutty_net - Today at 03:59:48 AMI saw this listed in the OPNsense 26.7.8 release notes and I can't wait to try it out. Congrats on the release, and thank you to everyone who made it possible!
#5
26.7, 26.10 Series / Re: 26.7.7: Lark HTTPS connect...
Last post by alveston - Today at 02:58:47 AMIt may also help to compare the complete OPNsense build and configuration with the previous working version before attempting a rollback.
#6
26.7, 26.10 Series / Re: 26.7.7: Lark HTTPS connect...
Last post by alveston - Today at 02:58:17 AMQuote from: Brilliant Technologies Lt on November 02, 2026, 05:46:23 PMHello,I would also check the PF states and NAT translations for the affected client while reproducing the problem. The Default deny / state violation rule and BAD state messages are worth investigating, although they do not necessarily establish the root cause. Comparing packet captures on both LAN and WAN interfaces would be particularly useful.
After upgrading OPNsense to 26.7.7, several Lark (larksuite.com) features stopped loading, including Reports and Approvals. They worked before the upgrade. The same Mac and account work on a mobile hotspot but fail through the usual OPNsense network. The root cause has not been established.
Symptoms:
- https://oa.larksuite.com/report/record/entry stays blank and eventually reports a page error. Other Lark features are also affected.
- DNS lookup returns an Akamai CNAME chain and 95.100.110.24 / 95.100.110.20.
- curl -vI --connect-timeout 10 --max-time 20 https://oa.larksuite.com/ resolves both IPv4 addresses, attempts TCP/443 on each, then times out with error 28 before any TLS handshake. No IPv6 address was returned in this curl test.
- No VPN/proxy is enabled on the client. nslookup shows a loopback DNS resolver (127.0.2.2); its providing software has not been identified.
Checks attempted:
- Default IPv4/IPv6 allow rules from LAN network to any are present. Exact LAN subnet membership and routing/NAT topology still need verification.
- Added a temporary TCP/443 pass rule for the affected client to both destination IPs: no improvement.
- Temporarily disabling Suricata was attempted without improvement; independent confirmation that the service fully stopped is not available.
- Rebooted OPNsense: no improvement.
- A packet capture attempt yielded no usable capture, so WAN transmission and return traffic are not yet verified.
Logs:
Live View showed TCP/443 from the affected client to 95.100.110.24 blocked under 'Default deny / state violation rule'. TCP flags and exact correlation with a fresh connection attempt were not captured. Kernel logs also show 'pf: BAD state' and 'pf: loose state match' involving other clients; these are not proven related to this client's Lark failure.
Are there known 26.7.7 PF state, interface, NAT, or forwarding changes matching these symptoms? What minimal diagnostics can distinguish local PF/NAT/routing trouble from upstream connectivity trouble? If this matches a known regression, is there an officially recommended fix or targeted rollback?
The previous working version, full current build suffix, hardware/NIC details, wordle hint and full topology have not yet been collected and can be supplied if required.
Thank you.
#7
Development and Code Review / MCP Server
Last post by HappyDoer - Today at 12:39:39 AMHas there been any consideration of an official MCP (Model Context Protocol) server for OPNsense? MCP is the open standard AI assistants (Claude, ChatGPT, Copilot, local LLMs etc.) use to talk to external tools, and since OPNsense already has a comprehensive REST API it seems a natural fit.
This could be either a first-class project or a vetted community project linked from the documentation's "Community Plugins > Other" list.
From a quick review, these are the most developed projects at the moment:
An official server would help me with:
A quick GitHub search already turns up 42 OPNsense MCP server projects, so there's clearly demand. Unfortunately, effort is spread across many partial implementations rather than one complete, up-to-date server. Would the team consider either building one or working with an external maintainer to list a recommended community option in the docs?
This could be either a first-class project or a vetted community project linked from the documentation's "Community Plugins > Other" list.
From a quick review, these are the most developed projects at the moment:
- Pixelworlds/opnsense-mcp-server (appears abandoned and is now outdated), and the more active adrianfako/opnsense-mcp-server fork.
- vespo92/OPNSenseMCP, which has been mentioned on this forum before.
An official server would help me with:
- Security and trust - a firewall is the last place you want an unvetted tool holding admin credentials. An official server could use the API only, with least-privilege API users and a clear read-only mode, rather than relying on SSH or shell access.
- Keeping up with releases - community servers fall behind as the API changes between releases. If one was maintained alongside OPNsense, it would track those changes.
- Troubleshooting and auditing - asking "why can't VLAN 20 reach the NAS?" or "which rules are unused or overlapping?" and getting an answer based on the live config, logs and states.
- Safer changes - describing a change in plain language, then reviewing the exact rules, aliases or NAT entries proposed before they are applied.
A quick GitHub search already turns up 42 OPNsense MCP server projects, so there's clearly demand. Unfortunately, effort is spread across many partial implementations rather than one complete, up-to-date server. Would the team consider either building one or working with an external maintainer to list a recommended community option in the docs?
#8
Russian - Русский / Какое видеонаблюдение установи...
Last post by Max NV - Today at 12:23:13 AMЗдравствуйте!
Есть ли какое-нибудь видеонаблюдение для дома?
Простенькое, наподобие motion для Linux.
Есть ли какое-нибудь видеонаблюдение для дома?
Простенькое, наподобие motion для Linux.
#9
26.7, 26.10 Series / Re: cve-2026-98432 (linux behi...
Last post by paepcke - Today at 12:08:28 AMFrom my understanding the bug itself (a very rare race condition in the ip option set multiprocessing handling) is useless without further down the road support via more flexible tcp header options.
The full working exploit chain requirements are not disclosed yet - for obvious reasons - but the Anthropic sample exploit seems to need mptcp enabled tcp services and tcp options support for the 2nd step, thats why all current more complex IDS rules targeting tcp.
Simply blocking ALL ip-options seems to be right choice here - after a review of the corresponding RFCs that define most of the prehistoric use cases.
Thanks for the qualified Feedback!
OPNsense/pf seems to be well equipped for the coming CVE-2026-98432 Linux Apocalypse. No need to inspect the tcp options in this case.
#10
26.7, 26.10 Series / Re: Likely messed up NAT conve...
Last post by really_lost - Today at 12:02:53 AMInstalling the legacy firewall plug-in, performing the migration I missed on NAT, and uninstalling the legacy plugin worked.
