Recent posts

#1
Good news. Now that it works, i would suggest to try to understand the meaning/ use of each settings: it will greatly help you in case you need changes to the config or restore the settings.

 
#2
Correct, I always forget that many people hosts service externslly reachable.
I do not hosts anythying like that nor i use vpn frm the outside, at least for my casr i'd say there is no extra protection...or I am not considering something?
#3
Quote from: Patrick M. Hausen on March 19, 2026, 10:23:36 PM
Quote from: FredFresh on March 19, 2026, 09:36:39 PMWhat if I have to whitelist some domain blocked by qfeeds?

I use AdGuard Home for DNS based blocking. It works well with Q-Feeds and you have a very good Web UI to add exceptions - either allowing domains or exempting certain internal hosts from filtering or whatever you might need.

I am using unbound, you mean that even if the qfeed blocklist is not mentioned inside unbound the whitelist management is still the same, correct?
Thanks
#4
26.1 Series / Re: cloidflare blocklist
Last post by FredFresh - Today at 06:51:34 AM
I am asking  if someone already has a link to that lists / lists...

I do not need pihole, we have opnsense that can manage that
#5
26.1 Series / IPv6 prefix modifcation crashi...
Last post by jaykumar2005 - Today at 06:42:04 AM

Looks like the issue reported here https://forum.opnsense.org/index.php?topic=49131.msg249523#msg249523 is back in 26.1.4 . I have a working IPv6 setup with /64 prefix delegation from ISP (PPPoe), but any attempt to change "Prefix delegation size" with "Send prefix hint" crashes the firewall. I am able to consistently reproduce this, every time I attempt to change these values, router crashes and reboots.

Versions
OPNsense 26.1.4-amd64
FreeBSD 14.3-RELEASE-p9
OpenSSL 3.0.19


[969470]
[969470]
[969470] Fatal trap 12: page fault while in kernel mode
[969470] cpuid = 4; apic id = 08
[969470] fault virtual address = 0x10
[969470] fault code = supervisor read data, page not present
[969470] instruction pointer = 0x20:0xffffffff80e0d175
[969470] stack pointer         = 0x28:0xfffffe0149887a80
[969470] frame pointer         = 0x28:0xfffffe0149887ab0
[969470] code segment = base 0x0, limit 0xfffff, type 0x1b
[969470] = DPL 0, pres 1, long 1, def32 0, gran 1
[969470] processor eflags = interrupt enabled, resume, IOPL = 0
[969470] current process = 10545 (tailscaled)
[969470] rdi: fffff8000244f000 rsi: 000000000000001c rdx: fffff806f7d2f078
[969470] rcx: fffff8000244f000  r8: 00000000ffffffbd  r9: 0000000000000000
[969470] rax: 0000000000000000 rbx: 0000000000000000 rbp: fffffe0149887ab0
[969470] r10: fffffe0149887a30 r11: 0000000000000008 r12: fffff80398e23298
[969470] r13: 0000000000000000 r14: fffffe0149887a8c r15: 0000000000010200
[969470] trap number = 12
[969470] panic: page fault
[969470] cpuid = 4
[969470] time = 1773944620
[969470] KDB: stack backtrace:
[969470] db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe01498877d0
[969470] vpanic() at vpanic+0x161/frame 0xfffffe0149887900
[969470] panic() at panic+0x43/frame 0xfffffe0149887960
[969470] trap_pfault() at trap_pfault+0x3da/frame 0xfffffe01498879b0
[969470] calltrap() at calltrap+0x8/frame 0xfffffe01498879b0
[969470] --- trap 0xc, rip = 0xffffffff80e0d175, rsp = 0xfffffe0149887a80, rbp = 0xfffffe0149887ab0 ---
[969470] in6_selecthlim() at in6_selecthlim+0x95/frame 0xfffffe0149887ab0
[969470] tcp_default_output() at tcp_default_output+0x1ca4/frame 0xfffffe0149887c70
[969470] tcp_usr_disconnect() at tcp_usr_disconnect+0x77/frame 0xfffffe0149887cb0
[969470] soclose() at soclose+0x75/frame 0xfffffe0149887d10
[969470] _fdrop() at _fdrop+0x11/frame 0xfffffe0149887d30
[969470] closef() at closef+0x24a/frame 0xfffffe0149887dc0
[969470] closefp_impl() at closefp_impl+0x58/frame 0xfffffe0149887e00
[969470] amd64_syscall() at amd64_syscall+0x117/frame 0xfffffe0149887f30
[969470] fast_syscall_common() at fast_syscall_common+0xf8/frame 0xfffffe0149887f30
[969470] --- syscall (6, FreeBSD ELF64, close), rip = 0x49c1bf, rsp = 0x86d1814f8, rbp = 0x86d1814f8 ---
[969470] KDB: enter: panic
panic.txt0600001215157037454  7144 ustarrootwheelpage faultversion.txt0600007515157037454  7550 ustarrootwheelFreeBSD 14.3-RELEASE-p9 stable/26.1-n272033-b4ddb3e0f150 SMP
#6
26.1 Series / Re: Do I need reinstall? Give ...
Last post by gnsinfo - Today at 06:39:21 AM
Quote from: meyergru on March 19, 2026, 09:02:30 PMToo little information given here. Sounds like a router-behind-router setup. See this, especially points 1, 4 and 16.

And BTW: There is no such thing as "lo0 routing".



Thanks, solved.
I add Firewall rule to LAN.
I can ping 192.168.55.127.^^*
#7
26.1 Series / Re: Do I need reinstall? Give ...
Last post by gnsinfo - Today at 06:23:24 AM
Thanks for all the reply.
To archive good communication, I used AI skills.


I finally found why I couldn't ping **192.168.55.127** and **.254** from my LAN client (**192.168.55.51**).

The issue is related to the **Gateway Group** configuration for Multi-WAN redundancy.
When I specify the Gateway Group in the "Gateway" field of the LAN firewall rule, OPNsense stops responding to ICMP and DNS queries directed to itself.

**Diagnostic Findings:**

1. According to the firewall logs, traffic from **.51** to **.127** is being **NATed on the WAN interface**.
   
2. It seems that because of Policy-Based Routing (PBR), the firewall forces local traffic out through the WAN gateway instead of routing it locally.
   
3. I switched Outbound NAT from "Automatic" to "Hybrid" and added a "No NAT" rule for LAN-to-LAN traffic. Now the traffic passes the firewall, but there is still **no reply**.
   

**My Question:**

Where is my traffic going, and why isn't the firewall intercepting traffic destined for its own interface when a Gateway Group is active?

How can I properly use Gateway Load Balancing/Failover while ensuring that traffic destined for the LAN Gateway or Virtual IPs (VIPs) is excluded from the Policy-Based Routing?

Thanks for all of your effort.
Good days all in all.
#8
25.7, 25.10 Series / OPNcentral Overwriting API Key...
Last post by amuckart - Today at 06:07:36 AM
The documentation for opncentral says:
QuoteWhen users and groups are synchronized, the existing api key+secret is merged into the user with the same name to prevent access issues after reconfigure. To avoid issues, make sure there's a unique username with proper credentials before using the synchronization.

What conditions are required to make this work?

Running OPNcentral on OPNsense 25.10.2_4-amd64 if I have an 'opncentral' user on the firewall being managed, and I generate an API for that user and use it to connect to the firewall from OPNcentral, as soon as I provision the managed firewall the API key either gets erased if there isn't one on the OPNcentral machine, or overwritten by the one on the OPNcentral machine if there is. That immediately breaks access to the managed device until I regenerate an API key and add it back in to OPNcentral.

It seems like this is not the intended behaviour, but I can't figure out what the settings need to be to make this work.

Can anyone enlighten me?

Thanks.
#9
General Discussion / Re: Internet access problems
Last post by Jebecca - Today at 05:18:41 AM
Quote from: nero355 on March 09, 2026, 10:47:43 PM
Quote from: Jebecca on March 09, 2026, 09:19:39 PMISC DHCPv4 Server and Dnsmasq DNS/DHCP are running.
AFAIK you can not run those at the same time ?!
I have now removed ISC DHCPv4 & v6 from the system. I am using Outbound DNS with Dnsmasq DNS/DHCP.
Thanks for the advice.
#10
General Discussion / Re: WAN IPv6 Privacy Extension...
Last post by drosophila - Today at 04:43:49 AM
I know this is necromancy but this issue has crept up for me as well, and I decided on the sledgehammer (do what you were already suggesting with removal through ifconfig). The tunables seem to be working if the interface is configured via SLAAC, but not when doing NAT. Maybe there is a way to do this less invasively, preferredly through the GUI? If so please comment!

I put a script into /usr/local/etc/rc.syshook.d/start/11-removeslaacwan
#!/bin/sh
MAC1=`ifconfig re1 |grep ether|cut -w -f 3|cut -d\: -f 1`
MAC2=`ifconfig re1 |grep ether|cut -w -f 3|cut -d\: -f 2`
MAC3=`ifconfig re1 |grep ether|cut -w -f 3|cut -d\: -f 3`
MAC4=`ifconfig re1 |grep ether|cut -w -f 3|cut -d\: -f 4`
MAC5=`ifconfig re1 |grep ether|cut -w -f 3|cut -d\: -f 5`
MAC6=`ifconfig re1 |grep ether|cut -w -f 3|cut -d\: -f 6`
tvar=`echo  $(( 0x$MAC1 + 0x2 ))`
pvar=`printf "%x" ${tvar}`
MAC1_="${pvar}"
SLAACMAC="${MAC1_}${MAC2}:${MAC3}ff:fe${MAC4}:${MAC5}${MAC6}"
testvar=`ifconfig re1|grep "inet6\ 2"|grep "${SLAACMAC}"|cut -w -f 3`
restvar=`ifconfig re1|grep "inet6\ 2"|grep "${SLAACMAC}"|cut -w -f 5`
if [ "${testvar}" ]; then
ifconfig re1 inet6 "${testvar}" remove
# ifconfig re1 inet6 "${testvar}/${restvar}"
echo "Address ${testvar}/${restvar} handled."
else
echo "No matching address found."
fi
The commented-out "adding back" the address may be desired since it places the address at the end of the list hoping the picker might ignore it because it finds another viable address before reaching this. It also clears the "automatic" flags, for better or worse. Might be worthwhile for inbound connectivity.

This has not been tested extensively (in fact, I just whipped it up), so it might break stuff. In my case, the gateway monitor goes red on the IPv6 gateway despite it being perfectly reachable. More testing needed.