"Recent posts
#1
26.1 Series / 26.1 seems break Tailscale Mag...
Last post by tony_vFG - Today at 05:58:20 AMI recently updated to 26.1 from 25.7.11_9. After upgrading OPNsense, Tailscale's MagicDNS no longer works.
The DNS server 100.100.100.100 can no longer resolve Tailscale's specific domain name like example.ts.net to Tailscale's 100.x.y.z IP addresses. This previously worked on the 25.7 series.
This is how I set up my Tailscale in 25.7:
1. First, install the official Tailscale plugin.
2. In the firewall's NAT outbound NAT settings, I set it to hybrid outbound NAT and added a manual rule that allows Tailscale to go through (following this thread).
3. After that, set up a split DNS that maps the resolver for Tailscale-specific domain to 100.100.100.100.
For me, I have the DNS servers running in Pi-hole and AdGuard Home as a Docker container on another host or under my network.
For Pi-hole, go to Setting > DNS. Under Conditional Forwarding, add an entry that forwards all Tailscale requests like this:
And the results are as followed:
This is what's shown when running drill in OPNsense.
26.1.3 (os-tailscale 1.4, tailscale 1.94.1_1):
Going back the snapshot 25.7.11_9 (os-tailscale 1.3, tailscale 1.92.2):
In the upgrade process of 26.1, nothing really changed except the OS version. I didn't migrate the firewall rules to use the new firewall rules, as I expect the old rules should still be working in the new 26.1 system.
Googling yields no possible solution except for one Reddit user who faced the same situation as me.
Luckily, my OPNsense is running on a virtualised system, and I did take a snapshot before upgrading. I can verify that after going back to the 25.7 snapshot, the whole network can still visit remote hosts through Tailscale FQDN without any issue.
This thread is placed under the 26.1 Series sub-forum instead of the VPN sub-forum since it is occurred only due to a change in version rather than a VPN usage problem.
The DNS server 100.100.100.100 can no longer resolve Tailscale's specific domain name like example.ts.net to Tailscale's 100.x.y.z IP addresses. This previously worked on the 25.7 series.
This is how I set up my Tailscale in 25.7:
1. First, install the official Tailscale plugin.
2. In the firewall's NAT outbound NAT settings, I set it to hybrid outbound NAT and added a manual rule that allows Tailscale to go through (following this thread).
3. After that, set up a split DNS that maps the resolver for Tailscale-specific domain to 100.100.100.100.
For me, I have the DNS servers running in Pi-hole and AdGuard Home as a Docker container on another host or under my network.
For Pi-hole, go to Setting > DNS. Under Conditional Forwarding, add an entry that forwards all Tailscale requests like this:
Code Select
true,100.64.0.0/10,100.100.100.100,tail12345.ts.netThis is pretty much the same for AdGuard Home, which adds an entry to the upstream DNS Servers:Code Select
[/tail12345.ts.net/]100.100.100.100And the results are as followed:
| OPNsense | Ping 100.x.y.z (including 100.100.100.100) | Ping Tailscale FQDN | SSH remote hosts using 100.x.y.z | SSH Tailscale FQDN | nslookup/dig/drill Tailscale FQDN |
| 25.7.11_9 | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ |
| 26.1.3 | ✔️ | ❌ | ✔️ | ❌ | ❌ |
This is what's shown when running drill in OPNsense.
26.1.3 (os-tailscale 1.4, tailscale 1.94.1_1):
Code Select
# drill @100.100.100.100 opnsense.example.ts.net
;; ->>HEADER<<- opcode: QUERY, rcode: SERVFAIL, id: 34065
;; flags: qr aa rd ; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;; opnsense.example.ts.net. IN A
;; ANSWER SECTION:
;; AUTHORITY SECTION:
;; ADDITIONAL SECTION:
;; Query time: 0 msec
;; SERVER: 100.100.100.100
;; WHEN: Tue Mar 10 12:59:53 2026
;; MSG SIZE rcvd: 43Going back the snapshot 25.7.11_9 (os-tailscale 1.3, tailscale 1.92.2):
Code Select
# drill @100.100.100.100 opnsense.example.ts.net
;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 37476
;; flags: qr aa rd ra ; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;; opnsense.example.ts.net. IN A
;; ANSWER SECTION:
opnsense.example.ts.net. 600 IN A 100.78.7.40
;; AUTHORITY SECTION:
;; ADDITIONAL SECTION:
;; Query time: 0 msec
;; SERVER: 100.100.100.100
;; WHEN: Tue Mar 10 13:02:56 2026
;; MSG SIZE rcvd: 84In the upgrade process of 26.1, nothing really changed except the OS version. I didn't migrate the firewall rules to use the new firewall rules, as I expect the old rules should still be working in the new 26.1 system.
Googling yields no possible solution except for one Reddit user who faced the same situation as me.
Luckily, my OPNsense is running on a virtualised system, and I did take a snapshot before upgrading. I can verify that after going back to the 25.7 snapshot, the whole network can still visit remote hosts through Tailscale FQDN without any issue.
This thread is placed under the 26.1 Series sub-forum instead of the VPN sub-forum since it is occurred only due to a change in version rather than a VPN usage problem.
#2
26.1 Series / Re: Upgrade went wrong
Last post by newsense - Today at 05:07:39 AMAs good as it gets. The warning will go away eventually whenever a newer pkg is ready.
#3
Hardware and Performance / Re: DEC740 Power Supply
Last post by zanfar - Today at 03:49:07 AMThank you.
The sticker on the bottom of my unit only has serial, P/N, MAC, and "made in" disclosures.
However, I did find a MeanWell 12V 3A brick in my box of cables which both fits and seems a reasonable specification.
The sticker on the bottom of my unit only has serial, P/N, MAC, and "made in" disclosures.
However, I did find a MeanWell 12V 3A brick in my box of cables which both fits and seems a reasonable specification.
#4
Hardware and Performance / Re: DEC740 Power Supply
Last post by OPNenthu - Today at 03:25:10 AMCheck for a sticker on the bottom of the unit.
For example the DEC695 bottom view: https://wiki.junicast.de/en/junicast/review/opnsense_dec695
According to the same site, their DEC740 arrived with a "Meanwell quality power supply 12V 3A." It's possible Deciso changed suppliers over time or by region.
For example the DEC695 bottom view: https://wiki.junicast.de/en/junicast/review/opnsense_dec695
According to the same site, their DEC740 arrived with a "Meanwell quality power supply 12V 3A." It's possible Deciso changed suppliers over time or by region.
#5
Hardware and Performance / Re: State of i226 compatibilit...
Last post by BrandyWine - Today at 03:14:36 AMThe issue with i226 was the nvram. Drivers work a-ok.
4x 226 + 1 or 2 sfp+ ports , seems good for doing some expansion.
N355 is about 2x the N150 on all fronts (more threads, more power, and price).
4x 226 + 1 or 2 sfp+ ports , seems good for doing some expansion.
N355 is about 2x the N150 on all fronts (more threads, more power, and price).
#6
Hardware and Performance / DEC740 Power Supply
Last post by zanfar - Today at 03:02:24 AMI bought a DEC740 over a year ago, but shortly had to unexpectedly move. Unfortunately, the DEC power supply either got lost in the move, or was dumped into a box of other random wall-warts and barrel PSUs. So now I either don't have one anymore, or I cannot locate the correct one. None of the bricks I can find have anything close to an OPNsense logo or marking--but I expect the correct PSU won't either.
Can someone provide the specs for the DC Input of the DEC740? Or, at worst, a source to buy a spare?
I have checked all the OPNsense hardware pages and docs, but cannot locate the answer--they only list the AC input of the PSU, not the specs from the PSU to the DEC. If you know where to find it, that would be appreciated as well.
Thanks in advance,
Can someone provide the specs for the DC Input of the DEC740? Or, at worst, a source to buy a spare?
I have checked all the OPNsense hardware pages and docs, but cannot locate the answer--they only list the AC input of the PSU, not the specs from the PSU to the DEC. If you know where to find it, that would be appreciated as well.
Thanks in advance,
#7
26.1 Series / Re: Upgrade went wrong
Last post by ezhik - Today at 02:49:53 AMQuote from: newsense on Today at 02:25:36 AMReinstall elastic with
# pkg install -f elasticsearch8
The rest looks good.
DONE:
Code Select
***GOT REQUEST TO AUDIT HEALTH***
Currently running OPNsense 26.1.3 (amd64) at Mon Mar 9 21:46:57 EDT 2026
>>> Root file system: zroot/ROOT/default
>>> Check installed kernel version
Version 26.1.3 is correct.
>>> Check for missing or altered kernel files
No problems detected.
>>> Check installed base version
Version 26.1.3 is correct.
>>> Check for missing or altered base files
No problems detected.
>>> Check installed repositories
OPNsense (Priority: 11)
SunnyValley (Priority: 7)
>>> Check installed plugins
pkg: warning: database version 37 is newer than libpkg(3) version 36, but still compatible
os-ddclient 1.30
os-isc-dhcp 1.0_4
os-qemu-guest-agent 1.3
os-sensei 2.4.1
os-sensei-agent 2.4
os-sensei-updater 1.18
os-sunnyvalley 1.5_2
os-theme-cicada 1.41
os-theme-rebellion 1.9.4
os-theme-tukan 1.31
os-theme-vicuna 1.51
>>> Check locked packages
pkg: warning: database version 37 is newer than libpkg(3) version 36, but still compatible
>>> Check for missing package dependencies
pkg: warning: database version 37 is newer than libpkg(3) version 36, but still compatible
Checking all packages: .......... done
>>> Check for missing or altered package files
pkg: warning: database version 37 is newer than libpkg(3) version 36, but still compatible
Checking all packages: .......... done
>>> Check for core packages consistency
Core package "opnsense" at 26.1.3 has 67 dependencies to check.
Checking packages: .................................................................... done
***DONE***
#8
26.1 Series / Re: Upgrade went wrong
Last post by newsense - Today at 02:25:36 AMReinstall elastic with
# pkg install -f elasticsearch8
The rest looks good.
# pkg install -f elasticsearch8
The rest looks good.
#9
26.1 Series / Re: Upgrade went wrong
Last post by ezhik - Today at 02:07:01 AMQuote from: newsense on Today at 01:29:35 AMQuote from: ezhik on Today at 01:01:44 AMWhat do you mean a manual complication? I did not install it manually. I run vanilla OPNSense.
OPNsense has extensive check to make sure the FreeBSD repos are disabled.
The fact you ended up with pkg from FreeBSD instead of the one from OPN means that the system was modified on purpose by "something" which in turn pulled packages from FreeBSD. This is why you're seeing the db version mismatch after you reverted pkg to the one in OPN.
The db warning is not catastrophic to my knowledge so you can continue to use the system as is.
More importantly though it may be possible to have there other packages from other repos that may cause trouble in the future.
For now it would be best to post here an audit so we can get a better understanding of where you're at.
It is weird indeed...
Attaching "audit: health"
Code Select
***GOT REQUEST TO AUDIT HEALTH***
Currently running OPNsense 26.1.3 (amd64) at Mon Mar 9 21:05:23 EDT 2026
>>> Root file system: zroot/ROOT/default
>>> Check installed kernel version
Version 26.1.3 is correct.
>>> Check for missing or altered kernel files
No problems detected.
>>> Check installed base version
Version 26.1.3 is correct.
>>> Check for missing or altered base files
No problems detected.
>>> Check installed repositories
OPNsense (Priority: 11)
SunnyValley (Priority: 7)
>>> Check installed plugins
pkg: warning: database version 37 is newer than libpkg(3) version 36, but still compatible
os-ddclient 1.30
os-isc-dhcp 1.0_4
os-qemu-guest-agent 1.3
os-sensei 2.4.1
os-sensei-agent 2.4
os-sensei-updater 1.18
os-sunnyvalley 1.5_2
os-theme-cicada 1.41
os-theme-rebellion 1.9.4
os-theme-tukan 1.31
os-theme-vicuna 1.51
>>> Check locked packages
pkg: warning: database version 37 is newer than libpkg(3) version 36, but still compatible
>>> Check for missing package dependencies
pkg: warning: database version 37 is newer than libpkg(3) version 36, but still compatible
Checking all packages: .......... done
>>> Check for missing or altered package files
pkg: warning: database version 37 is newer than libpkg(3) version 36, but still compatible
Checking all packages:
elasticsearch8-8.11.3: checksum mismatch for /usr/local/lib/elasticsearch/lib/jna-0.0.0.jar
Checking all packages............. done
>>> Check for core packages consistency
Core package "opnsense" at 26.1.3 has 67 dependencies to check.
Checking packages: .................................................................... done
***DONE***
#10
General Discussion / Re: Opnsense DOSing upstream D...
Last post by newsense - Today at 01:46:54 AMThere are two options available in both Unbound and Dnsmasq that are not exposed in the GUI, that can help with minimizing the outbound DNS traffic.
It would be best to open a feature request ticket on GitHub OPNsense/core for this referencing this thread.
It is important to have these options to both resolvers since people may use one resolver or another.
Quote—max-cache-ttl=<time>
Set a maximum TTL value for entries in the cache.
--min-cache-ttl=<time>
Extend short TTL values to the time given when caching them. Note that artificially extending TTL values is in general a bad idea, do not do it unless you have a good reason, and understand what you are doing. Dnsmasq limits the value of this option to one hour, unless recompiled.
It would be best to open a feature request ticket on GitHub OPNsense/core for this referencing this thread.
It is important to have these options to both resolvers since people may use one resolver or another.
