"Recent posts
#1
26.7 Series / Display ststus of scheduled ru...
Last post by MoonbeamFrame - Today at 09:46:33 AMIn the current Rules display scheduled rules no longer indicate their status while previously they were coloured green/orange for active/inactive.
Was this intentional?
#2
26.7 Series / Re: Dashboard services widget ...
Last post by dseven - Today at 09:41:12 AMYay! Another thread about the services widget!
https://forum.opnsense.org/index.php?topic=52348
https://forum.opnsense.org/index.php?topic=52380
https://forum.opnsense.org/index.php?topic=52390
https://forum.opnsense.org/index.php?topic=52407
BTW, OPNsense doesn't have a set Dark Mode, but it does have themes. What theme are you using? With the included "opnsense-dark" theme, it should be black text, not white, although some people don't like that combination either ;)
https://forum.opnsense.org/index.php?topic=52348
https://forum.opnsense.org/index.php?topic=52380
https://forum.opnsense.org/index.php?topic=52390
https://forum.opnsense.org/index.php?topic=52407
BTW, OPNsense doesn't have a set Dark Mode, but it does have themes. What theme are you using? With the included "opnsense-dark" theme, it should be black text, not white, although some people don't like that combination either ;)
#3
26.7 Series / Re: Firewall rules and aliases...
Last post by mokaz - Today at 09:40:52 AMHum very bizarre, I now created the exact same alias with a different name and suddenly, within the firewall / diagnostics / aliases, the new alias as well as the former alias are now all populated with the correct subnets. Which wasn't the case on the original alias before (was empty within the diagnostics)
#4
26.7 Series / Re: Firewall rules and aliases...
Last post by MoonbeamFrame - Today at 09:38:31 AMNo, not at this time.
I also found that the 'fix' mentioned earlier did not persist after a reboot.
I also found that the 'fix' mentioned earlier did not persist after a reboot.
#5
26.7 Series / Re: Firewall rules and aliases...
Last post by mokaz - Today at 09:24:23 AMQuote from: MoonbeamFrame on July 22, 2026, 01:19:38 PMThe alias at the root of the problem is structured:
+----- Alias_NW1 subnet
|
Alias-+----- Alias_NW2 subnet
|
+----- Alias_NW3 + NW4 subnets
Hi,
Funny, I'm seeing roughly the same here; had to add a any/any/all/all rule for traffic to pass.
The used alias looks like this:
+----- Alias_SITE1 (10.x.x.x/16)
|
ALL-LAN-+----- Alias_SITE2 (10.x.x.x/16)
|
+----- Alias_SITE3 (10.x.x.x/16)
|
+----- + 3 other SITES aliases (site4,5,6)
Have you found a decent solution and better something to do before the update/upgrade? I had updated my local FW where I stand and could workaround the issue but remotely that may be more problematic..
Thank you
#6
Hardware and Performance / Re: Network setup with OPNsens...
Last post by Snoopy913 - Today at 08:49:59 AMQuote from: BrandyWine on July 24, 2026, 01:57:52 AMHow does the video get from vehicle to the livestream PC?
What's the internet link, your 5GLTE device? If everyone else is using the same cell then bandwidth could/might be impacted.
Anything streaming to a utoob channel, you can buy a small device from amzon or the like that takes in video (hdmi, composite, ntsc/pal), hardware encodes it, and then streams it to the utoob channel. So basically no work for that part, dont need a PC. Use the one that has eth port so no reliance on wifi.
Wifi for the team, you just need a wifi AP. What are they doing on the wifi (internet, other)?
Yes the 5G mobile Network cannot be used, as soon as some people are there, IT IS to crowded for streams.
We would Stream the in vehicle cameras via WiFi, for that the APs would be used. I currently just don't know which distance between the APs I can have to have a good coverage over the complete Track.
We will most likely have 4-5 fixed Cameras on Track, a drone and maybe the in vehicle cameras.
There is our first test this year, which started bad, but got better in the end.
https://youtube.com/playlist?list=PLJ-leheBA7Kg&si=0uBTGvQExG0eVx-8
#7
Hardware and Performance / Re: Network setup with OPNsens...
Last post by Snoopy913 - Today at 08:42:30 AMQuote from: nero355 on July 23, 2026, 04:23:13 PMQuote from: Snoopy913 on July 22, 2026, 09:16:42 PMIn total that would make 3 WAN connections for OPNsense and currently 3 partly separate networks.IMHO creating that setup is just annoying from all the topics that I have seen so far with Multi-WAN setups so I would use 3 seperate OPNsense Routers if your budget allows it :)
Can I define in OPNsense which vLAN is using which WAN connection? I want to make sure that the livestream has the highest priority.QuoteThe Video streams will have not more then 10Mbit but there is a protocol called NDI which we might use in the future and this could require a bandwidth of 100Mbit per 1080p stream, so the baseload of the network to the Livestreaming PC could exceed 500Mbit.Why such a high bitrate ?!
IIRC 1080p Blu-Ray doesn't even exceed 42 Mbps or so...
And with all the new codecs that came after that I am betting you could go even lower with the same quality! :)
But maybe your NDI protocol changes all of this ofcourse ?QuoteIf someone has a recommendations for good PoE outdoor APs for large areas, this would also be welcome.I guess that brings us very quickly back to Ubiquiti Outdoor UAPs if you want to keep things relatively cheap ?! ^_^
Good luck! with the project and let us know where to watch this when you all done with the setup ;)
Yes it's basicaly the NDI protocol which skyrockets the bandwidth, that's why I want to avoid it. If I can use some other protocol, Like SRT, we will be in the 10Mbps area.
I started planning with U7 Outdoor, but I have not yet found any tests on the what actual area coverage I can expect in the open field.
This was our first trial with the Livestream a 2 weeks ago, it started pretty bad, but got better in the end and we now know the areas we have to improve, like Camera and network:
https://youtube.com/playlist?list=PLJ-leheBA7Kg&si=0uBTGvQExG0eVx-8
In about a year, same channel, there will be our next possibility to Test the improvements.
#8
26.7 Series / Re: Unbound NXDOMAIN response ...
Last post by dinguz - Today at 07:56:02 AMNot exactly the same issue, but this has bitten me before.
Unbound has a hardcoded list of "special-use" zones that are treated as local and won't be resolved normally unless you explicitly override them in the configuration. Unfortunately, this cannot be configured through the OPNsense GUI, only through a manual Unbound config override.
The examples in the OPNsense documentation don't use any of these special-use domain names, which is why the forward lookup examples work as expected. The reverse lookup examples, however, do not work if they point to RFC 1918 address space. As soon as you use one of the domains listed below, the documented examples no longer behave as intended unless you add an explicit `local-zone: "<domain>." nodefault` override.
The list includes:
Unbound has a hardcoded list of "special-use" zones that are treated as local and won't be resolved normally unless you explicitly override them in the configuration. Unfortunately, this cannot be configured through the OPNsense GUI, only through a manual Unbound config override.
The examples in the OPNsense documentation don't use any of these special-use domain names, which is why the forward lookup examples work as expected. The reverse lookup examples, however, do not work if they point to RFC 1918 address space. As soon as you use one of the domains listed below, the documented examples no longer behave as intended unless you add an explicit `local-zone: "<domain>." nodefault` override.
The list includes:
Code Select
localhost.
127.in-addr.arpa.
1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa.
home.arpa.
resolver.arpa.
service.arpa.
onion.
test.
invalid.
10.in-addr.arpa.
16.172.in-addr.arpa.
17.172.in-addr.arpa.
18.172.in-addr.arpa.
19.172.in-addr.arpa.
20.172.in-addr.arpa.
21.172.in-addr.arpa.
22.172.in-addr.arpa.
23.172.in-addr.arpa.
24.172.in-addr.arpa.
25.172.in-addr.arpa.
26.172.in-addr.arpa.
27.172.in-addr.arpa.
28.172.in-addr.arpa.
29.172.in-addr.arpa.
30.172.in-addr.arpa.
31.172.in-addr.arpa.
168.192.in-addr.arpa.
0.in-addr.arpa.
254.169.in-addr.arpa.
2.0.192.in-addr.arpa.
100.51.198.in-addr.arpa.
113.0.203.in-addr.arpa.
255.255.255.255.in-addr.arpa.
0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa.
d.f.ip6.arpa.
8.e.f.ip6.arpa.
9.e.f.ip6.arpa.
a.e.f.ip6.arpa.
b.e.f.ip6.arpa.
8.b.d.0.1.0.0.2.ip6.arpa.
This is upstream Unbound behavior rather than something specific to OPNsense. #9
26.7 Series / Re: Unbound NXDOMAIN response ...
Last post by muchacha_grande - Today at 04:19:21 AMI don't think that this is a specific problem to .lan domain. Don't rename it.
Just uncheck the option "Harden Below NXDOMAIN" and test it for some time to see if it works as you need.
Just uncheck the option "Harden Below NXDOMAIN" and test it for some time to see if it works as you need.
#10
26.1, 26,4 Series / Re: DEC840 slow upload test wh...
Last post by tedhughes - Today at 04:02:01 AMReviving this because I have the same symptom on the same hardware, and I've been able to rule out a lot of the variables you couldn't.
Setup
Symptom
Download 3.5-4.7 Gbps. Upload pinned at ~600-870 Mbps, consistently, regardless of test method or target. Notably it has twice briefly exceeded 1.1 Gbps mid-test before collapsing back — so it behaves like a dynamic loss mechanism, not a static cap.
The control test that matters
A Mac Studio connected directly to the ONT — same static IP, same cable, same ONT port — gets ~6 Gbps in both directions. Circuit, provisioning, and the ISP upload policer are all demonstrably fine. The cap only appears when traffic passes through the DEC840.
What I've ruled out (all measured, not assumed)
Packet-level finding
tcpdump on ax0 during upload shows SACK blocks in the returning ACKs across multiple independent flows:
Receivers are reporting gaps in the upload stream — frames leave ax0 and don't all arrive, while every counter on my side stays clean. Advertised receive windows on those flows also shrink under load (2045 -> 2003 -> 1972). Per-flow throughput works out to roughly 120-160 Mbit/s; 4-5 parallel flows sums to the observed ceiling.
Version ladder (tested identically at each step)
Continuing up the ladder; will update with results.
Tunables — factory Deciso defaults, unmodified:
Where this leaves it
The OP's switch-bypass test (ONT -> switch -> DAC -> SFP+, no copper transceiver in the path) produced no change, which points away from the transceiver and toward the ax TX path itself. I'm running the equivalent test on my side and will report back.
Two questions for anyone who's been here:
1. Has anyone with a DEC840/DEC850 achieved sustained multi-gig upload on ax0 with a real WAN — and if so, on what version?
2. Is there any known asymmetry in how axgbe handles TX for forwarded/NAT'd traffic vs locally-originated? Everything I can measure says the interface is healthy and the packets simply don't all survive the trip.
Happy to provide full pcaps or run any test that would help.
Setup
- DEC840, WAN on ax0, LAN on ax1 (8 tagged VLANs + untagged LAN)
- 8 Gbps symmetrical fiber, static /26, no PPPoE (key difference from OP's setup)
- WAN transceiver: FS SFP-10G-T (30m), on Deciso's tested-modules list for the DEC800 series
- LAN: passive SFP+ DAC to a UniFi 10G switch
Symptom
Download 3.5-4.7 Gbps. Upload pinned at ~600-870 Mbps, consistently, regardless of test method or target. Notably it has twice briefly exceeded 1.1 Gbps mid-test before collapsing back — so it behaves like a dynamic loss mechanism, not a static cap.
The control test that matters
A Mac Studio connected directly to the ONT — same static IP, same cable, same ONT port — gets ~6 Gbps in both directions. Circuit, provisioning, and the ISP upload policer are all demonstrably fine. The cap only appears when traffic passes through the DEC840.
What I've ruled out (all measured, not assumed)
- Forwarding capacity — iperf3 Mac <-> OPNsense, 8 streams: 9.11 Gbit/s aggregate
- LAN segment / DAC / switch — single stream: 2.65 Gbps up / 4.09 Gbps down, ~0 retransmits
- Interface errors — netstat -i -I ax0 -w 1 during sustained upload: zero errs, zero idrops, both directions
- CPU — top -aSH during upload: all cores essentially idle
- Shaper — pfctl -sq empty, no pipes/queues configured
- IDS/IPS/DPI — Suricata, Zenarmor, ntopng all stopped, nothing attached via netmap
- Hardware offload — CRC/TSO/LRO disabled, verified absent from ifconfig flags: no change
- pf scrub — disabled: no change
- MSS — SYN-ACKs show mss 1460, not clamped
- VPN policy routing — LAN clients egress the correct static IP
- Flow control — dev.ax.0.rx_pause/tx_pause=1 + reboot: no change, media line reports rxpause,txpause regardless
Packet-level finding
tcpdump on ax0 during upload shows SACK blocks in the returning ACKs across multiple independent flows:
Code Select
sack 1 {73849:78193}
sack 1 {53577:75297}
sack 1 {73849:101361}Receivers are reporting gaps in the upload stream — frames leave ax0 and don't all arrive, while every counter on my side stays clean. Advertised receive windows on those flows also shrink under load (2045 -> 2003 -> 1972). Per-flow throughput works out to roughly 120-160 Mbit/s; 4-5 parallel flows sums to the observed ceiling.
Version ladder (tested identically at each step)
| Version | FreeBSD base | Upload |
| 24.7.7 | 14.1 | ~600 Mbps |
| 24.7.12 | 14.1 | ~600 Mbps |
| 25.1.12 | 14.2 | ~600 Mbps |
Continuing up the ladder; will update with results.
Tunables — factory Deciso defaults, unmodified:
Code Select
dev.ax.0/1.iflib.override_nrxds = 2048 x8
dev.ax.0/1.iflib.override_ntxds = 2048 x8
dev.ax.0/1.link_workaround = 1
dev.ax.sph_enable = 0Where this leaves it
The OP's switch-bypass test (ONT -> switch -> DAC -> SFP+, no copper transceiver in the path) produced no change, which points away from the transceiver and toward the ax TX path itself. I'm running the equivalent test on my side and will report back.
Two questions for anyone who's been here:
1. Has anyone with a DEC840/DEC850 achieved sustained multi-gig upload on ax0 with a real WAN — and if so, on what version?
2. Is there any known asymmetry in how axgbe handles TX for forwarded/NAT'd traffic vs locally-originated? Everything I can measure says the interface is healthy and the packets simply don't all survive the trip.
Happy to provide full pcaps or run any test that would help.
