Quote from: somanet on Today at 06:13:32 AMConfigure the OPNfirewall with interface WAN port
to operate with a public ip My question is is it safe ?
Quote from: franco on Today at 11:21:56 AMI'll discuss with Stephan.Is there any progress/news about the other discussions that we had some time ago about the New Firewall Rules page and similar situations like the KEA DHCP Leases related page ?
Quote from: franco on Today at 08:27:17 AMApprently this made some waves looking at https://github.com/freebsd/freebsd-ports/commit/3c11b048c3d -- in theory we could flip it back but I'll have to discuss internally. The minimum optimization requirement was probably done for a good reason.
Quote from: wincent on Today at 08:43:17 AMI'm glad to hear this.It was not exactly easy to find, but I guess you could check this : https://numpy.org/doc/stable/user/troubleshooting-importerror.html#segfaults-or-crashes
It's a tough decision. After all, OPNSense focuses on security performance, and Unbound DNS reporting is just a plug-in functional component. However, many firewall platforms or all-in-one servers may not be equipped with the latest CPU, and I believe many users still require this functionality.
Quote from: franco on June 10, 2026, 05:20:58 PM> fetch: /usr/local/opnsense/changelog/changelog.txz.sig appears to be truncated: 0/1332 bytesThis tip got me somewhere. I use local DNS (adguard with unbound as upstream) which is run separately from opnsense. On backup node Unbound doesn't work, initially I thought it was because of not available interfaces (ipv6 tunnel) unbound is binded to. But after deselecting them still doesn't work issuing error:
Usually a sign of DNS timeouts.
Unable to open pipe. This is likely because Unbound isn't running.root@OPNsense-bkp:~ # dig opnsense.org
;; communications error to 127.0.0.1#53: connection refused
;; communications error to 127.0.0.1#53: connection refused
;; communications error to 127.0.0.1#53: connection refused
;; communications error to 172.16.1.4#53: timed out
;; communications error to 2001:xxxxxxxxx::4#53: timed out
; <<>> DiG 9.20.22 <<>> opnsense.org
;; global options: +cmd
;; no servers could be reachedroot@OPNsense-bkp:~ # ping 172.16.1.4
PING 172.16.1.4 (172.16.1.4): 56 data bytes
64 bytes from 172.16.1.4: icmp_seq=0 ttl=64 time=0.227 ms
64 bytes from 172.16.1.4: icmp_seq=1 ttl=64 time=0.105 ms
--- 172.16.1.4 ping statistics ---
2 packets transmitted, 2 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.105/0.166/0.227/0.061 ms
root@OPNsense-bkp:~ # nc -vzu 172.16.1.4 53
Connection to 172.16.1.4 53 port [udp/domain] succeeded!QuoteDo not use the local DNS service as a nameserver for this system
root@OPNsense-bkp:~ # dig opnsense.org
; <<>> DiG 9.20.22 <<>> opnsense.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40326
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;opnsense.org. IN A
;; ANSWER SECTION: opnsense.org. 3 IN A 89.149.225.137
;; Query time: 0 msec
;; SERVER: 172.16.1.4#53(172.16.1.4) (UDP)
;; WHEN: Thu Jun 11 09:57:59 CEST 2026
;; MSG SIZE rcvd: 57 ***GOT REQUEST TO CHECK FOR UPDATES***
Currently running OPNsense 26.1.9 (amd64) at Thu Jun 11 10:00:41 CEST 2026
Fetching changelog information, please wait... fetch: transfer timed out
fetch: /usr/local/opnsense/changelog/changelog.txz appears to be truncated: 0/217364 bytes
done
Updating OPNsense repository catalogue...
Waiting for another process to update repository OPNsense
All repositories are up to date.
Checking for upgrades (107 candidates): .......... done
Processing candidates (107 candidates): . done
Checking integrity... done (0 conflicting)
Your packages are up to date.
***DONE***Quote from: OPNenthu on June 10, 2026, 10:30:58 PMQuick update-
The DNS storm seems to have stopped overnight but I'm not sure why.
Quote from: Sandyman on February 25, 2026, 06:55:10 PMHello
I look after two sites in a relatively remote area, they are about 1km apart. Both sites have relatively high speed FTTP links (c. 300Mbps). It is possible to install a wireless bridge between the sites. It would be beneficial to install a cellular WAN, because cars frequently take the telegraph poles out causing weeks of outage! However, only one site (site A) has cellular coverage.
Assuming that both site A and site B have OPNsense units, that a wireless bridge link (WBL FNF) is available, say using a TP-Link EAP215, and a cellular WAN at site A.
Is the following possible with OPNsense?
• Allowing the sub nets at site A and site B to communicate using the WBL
• Allowing site B to use the cellular WAN in case of FTTP failure at site B
If so, could you give me a pointer as to the features / configuration to explore?
Is there an easier way, perhaps I have missed something obvious?
Thank you in advance.