Messages

In my case, I can confirm that I didn't see any other `notice: send failed: No buffer space available` error since I changed the Unbound DNS forwarder to be different than the gateway monitor IP.

Interestingly, I didn't see new unbound error messages since the forwarder modification.
Perhaps that's the culprit, since my forwarder was also set as gateway monitor IP for one of my WAN links, it had a static route configured.
This could create problems when WAN link is down, and perhaps generate too much connections from both dpinger and unbound.

Really nice tutorial.
I have done something alike some years ago with GUAs only since my ISP gives me a /56 network, but then again Orange (my french ISP), told me that they don't provide static IPv6 even for my profesionnal WAN link (yes! they don't provide static IPv6 in 2026 for their smaller professionel customers).

Finally, I like your ULA<--NAT-->GUA solution since I don't need to change my GUA prefix everytime Orange decides it's time to change my public IPv6.

I did read a bit about the general preference of GUAs over ULAs in this post, but would love to get a small "why ULAs are good/bad ?" answer.
The only downside I see is that IPv4 is preferred over IPv6 in case of ULAs. Is there anything else I should account for ?

Thank you.

Seeing the same issue here with OPNsense 26.1.11_6-amd64 (but agreed, this happens since a months or two for me).


I noticed that the Unbound logs are full of the following logs:
```
2026-07-09T00:10:21Noticeunbound[57596:0] notice: send failed: No buffer space available
2026-07-09T00:10:20Noticeunbound[57596:4] notice: remote address is 9.9.9.9 port 53
2026-07-09T00:10:20Noticeunbound[57596:4] notice: send failed: No buffer space available
2026-07-09T00:10:20Noticeunbound[57596:5] notice: remote address is 9.9.9.9 port 53
2026-07-09T00:10:20Noticeunbound[57596:5] notice: send failed: No buffer space available
2026-07-09T00:10:20Noticeunbound[57596:2] notice: remote address is 9.9.9.9 port 53
2026-07-09T00:10:20Noticeunbound[57596:2] notice: send failed: No buffer space available
2026-07-09T00:10:20Noticeunbound[57596:3] notice: remote address is 9.9.9.9 port 53
```

Firewall is quite used:
```
memory
- states: 3067500
- src-nodes: 3067500
- frags: 5000
- table-entries: 8000000
```
As for the suggested sysctl value, I have the default setting `kern.ipc.maxsockbuf: 4262144` for now.

I'm running WAN + LAN on a lagg interface with VLANs. Physical cards are Ethernet Controller X710 for 10GbE SFP+.
Also running Zenarmor (physical interface via L3 netmap native driver) + Suricata (on WAN links) and crowdsec.
I'm wondering whether the above three are compatible with each other.

Since I use 9.9.9.9 as gateway monitor IP for one of my WAN links, I switched unbound forwarder IP 9.9.9.9 to 8.8.4.4 in order to outrule too much traffic to that DNS resolver. Let's see.

honestly, I've fiddled around with like all possible solutions, tried on qemu v8 and v9, with various cpus.
Finally, I came up with this solution to add in `/boot/loader.conf` to get good performance.

```
hw.vtnet.X.tso_disable="1"
hw.vtnet.tso_disable="1"
hw.vtnet.lro_disable="1"
hw.vtnet.X.lro_disable="1"
hw.vtnet.csum_disable="1"
hw.vtnet.X.csum_disable="1"
```

Took the solution from https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=165059
Even with those settings, speed is good but far from what it should be (other people had the same https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=165059#c44).

Since I didn't check this bug report up for a while, I noticed that vtnet offload improvements landed in freebsd only a couple of days ago.
Perhaps things will be better now. I'll definitly need some testing.

In the meantime, I have a made that basic script to "cold" modify / inject data into an offline opnsense VM that solves an issue that may be gone soon.

Indeed, but with virtio, I previously had a -300% throughput difference once I use suricata, hence the reason I passthrough physical interfaces.
Perhaps this is solved more recently ?

I've written a (quick and dirty) script to handle a specific scenario for my OPNSense VM.

I'm hosting OPNSense on a KVM hypervisor with 10Gb NICs (named ixl0..9).
I backup that VM every night, and restore it on a second much smaller hypervisor which has 1Gb NICs (named igb0..9).
This is done because I don't want to handle a high availability scenario which is a quite insane amount of work (every interface needs a VRRP, and some of the plugins aren't HA aware, meaning more work).

Anyway, once I've restored the VM on my spare device, it won't work unless I rename my interfaces from ixl to igb, which makes sense.
In order to make things more smooth, I came up with (perhaps a bad) idea:

1. Mount restored disk image locally on backup KVM hypervisor
2. Replace interface names in config.xml
3. Unmount disk image
4. Profit !

So far, I came up with a script to handle this.
The script supposes that the host hypervisor has a running ZFS implementation, and can mount qemu disk images via qemu-nbd.

I'm pretty sure there might be better solutions, perhaps you could tell me how you manage cross hypervisor OPNsense backup/restore scenarios ?

Anyway, please find the script at https://github.com/deajan/linuxscripts/blob/master/virsh/offline_rename_opnsense_interfaces.sh

Any feedback is appreciated.

Makes perfect sense :)
Thank you.

Thanks for the reply.
I guess that means that if I setup a /64 on WAN, I will definitly need prefix delegation in order to get multiple /64 subnets, hence configure a DHCPv6 server on the BGP routers ?

Any perhaps "simpler" way to tell OPNSense that it's allowed to use the whole /48 net ?

Hello,

I'm an OPNsense user since almost 10 years now, and use it at home & work.
I've setup a couple of home ipv6 networks, where I had to use NPTv6 since ISP wouldn't hand out a bigger than /64 prefix delegation, so I have basic IPv6 knowledge.

My problem today is quite different.
I've setup bgp routers which have IPv4 and IPv6 sessions.
My bgp routers are bridged to my OPNSense, which has a DMZ vlan interface in which I have a couple of servers.

So far, my setup looks like:


(BGP-Router(s))--------[bridge]----------(OPNSense WAN_________OPNSense DMZ)----------[bridge]-------------[VM]
2001:X:Y:0::254/48 (VRRP)               2001:X:Y:0:1/48        2001:X:Y:FF:254/64                          2001:X:Y:FF::1/64     
2001:X:Y:0::253/48 (RTR1)               GW 2001:X:Y:0:254                                                  GW 2001:X:Y:FF:254
2001:X:Y:0::252/48 (RTR2)                   

I've setup the wan address as static since I don't plan on running a dhcp server on bgp routers.
I've setup the dmz address as static too, as well as the VM.

I can't ping the BGP routers from the VM (traceroute shows that it stops at opnsense). Ping to OPNsense works.
I can ping both the BGP routers and the VM from OPNSense.
I can ping OPNSense from the BGP routers.

I came to the conclusion that OPNSense doesn't route IPv6 from DMZ to WAN interface.
I did of course setup a ipv4/ipv6 any to any rule on DMZ interface for my tests.
I've also checked that ipv6 forwarding is enabled via:
```
# sysctl net.inet6.ip6.forwarding
net.inet6.ip6.forwarding: 1
```

My IPv6 routing table looks sane to me:
```
netstat -nr

[ipv4...]

Internet6:
Destination                       Gateway                       Flags         Netif Expire
default                           2001:X:Y:0::254   UGS          vtnet4
::1                               link#6                        UHS             lo0
2001:X:Y::/48                 link#5                        U            vtnet4
2001:X:Y:0::1         link#6                        UHS             lo0
2001:X:Y:FF::/64            link#25                       U            vlan04
2001:X:Y:FF::254            link#6                        UHS             lo0
fe80::%vtnet4/64                  link#5                        U            vtnet4
fe80::5054:ff:feb9:2fc7%lo0       link#6                        UHS             lo0
fe80::%lo0/64                     link#6                        U               lo0
fe80::1%lo0                       link#6                        UHS             lo0
fe80::%vlan04/64                  link#25                       U            vlan04
fe80::5054:ff:fe32:b0eb%lo0       link#6                        UHS             lo0
```

All my IPv4 networking works, so my problem looks really IPv6-only.
Since I've setup a /48 on WAN and a /64 on DMZ, is there anything else I should have configured except the firewall rule ?

Also, side question, since my VM in DMZ interface will be publicly accessible and have an AAAA record, I configured it with a static ipv6.
Is that a "good practice", or should I go a SLAAC / DHCP6 way ? If so, doesn't that make things more complicated when trying to find it's IP to setup AAAA records ?

Thanks for any insight.

At least they finally did something, and responded on bugzilla.
My last bug report really isn't worth their time... https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280615

Can confirm that 25.7rc2 fixes the issue for me.

Thank you guys, this made me question my network admin skills and/or sanity ;)

@meyergru: Thanks for the tip.
I've updated to 25.7rc2 and indeed the workaround fix from OPNsense team works.

I'm happy that there is a logical explanation, as I was just questioning my sanity :)

I use to deploy OPNsense on AlmaLinux with KVM, so I can backup / restore the whole VM in a couple of minutes.
Got very good results for years. Ping me if you need some advices (especially when not using PCI-passthrough for performance).

Hello,

I'm facing a real WTF situation and really could need some advice here.
I have a OPNSense FW (25.1.10), and cannot wrap my head around my issue.

Randomly, pings to 8.8.8.8 or 1.1.1.1 get blocked by the firewall.
From the same LAN subnet, some computers can ping, others can't.
After a while, other computers can't ping, and some that couldn't now can.

When looking at the firewall logs, the ICMP packets that get blocked are processed by the same rule as that passes other ICMP packets.
When clicking on the rule link, the window closes since the rule isn't found (see the attached screenshots).

In order to outrule some factors, I've:
- Disabled Zenarmor
- Disabled Suricata
- Disabled Crowdsec
- Marked my default gateway as always on (no monitoring)

When I ping 1.1.1.1 or 8.8.8.8 from the firewall itself, of course both respond.

I've also tried to check the Disable reply-to wan setting in firewall>settings>advanced.
I've checked that I don't have any special routes to 1.1.1.1 nor 8.8.8.8

This happened already with 24.7 series as far as I can remember.
I've just updated 25.1.10 to 25.1.11 and a computer that could ping 8.8.8.8 but couldn't ping 1.1.1.1 can now ping 1.1.1.1 but can't ping 8.8.8.8 anymore.
I've also exported my opnsense config file and searched for those IPs in order to make sure I didn't forget anything.
The only entry I found for 1.1.1.1 is for query forwarding in unbound.

I'm totally puzzled as why this is random.
I'd be grateful for any clue where to search for.

Thank you.