"Recent posts
#1
26.7 Series / APC UPS deamon plugin stopped ...
Last post by beneix - Today at 11:03:20 AMI performed a series of updates after returning from holidays. I updated 26.1.8_5 --> 26.1.11_10 --> 26.7.1_1 --> 26.7.2_2. The apcupsd plugin no longer starts and on the dashboard it states "Error: empty output from apcaccess". I think it broke already with the update to 26.1.11_10, but I am not sure.
Is this a known issue? There is no error in the log, just a notice that apcupsd is starting.
Is this a known issue? There is no error in the log, just a notice that apcupsd is starting.
#2
Zenarmor (Sensei) / Re: How to block Firefox VPN
Last post by sy - Today at 11:02:58 AMHi,
It seems different from QUIC issue. We need to check the config file.
It seems different from QUIC issue. We need to check the config file.
#3
General Discussion / TCP/53 fails when DNS response...
Last post by mveerman - Today at 10:49:42 AM## Problem
I am seeing a reproducible problem with **DNS over TCP through OPNsense**. The failure is strongly correlated with the size of TCP segments/packets.
The problem is not specific to Unbound or to a particular upstream DNS provider.
## Environment
* OPNsense is the gateway/firewall.
* Ziggo modem: `192.168.78.1`
* OPNsense WAN IP: `192.168.178.12`
* WAN interface: `ue0`
* Test query:
`drill -t @192.168.178.1 rdw.nl DNSKEY`
* The DNSKEY response is approximately 724 bytes.
## Reproduction
With a TCP MSS normalization rule applied to the LAN traffic:
* MSS **700** → DNSKEY query fails
* MSS **800** → DNSKEY query succeeds
* MSS **500** → DNSKEY query fails
This is highly reproducible.
At MSS 700, the TCP handshake succeeds and the DNS query is successfully delivered to `192.168.178.1:53`. The client then waits for the DNS response and eventually closes the connection.
Example:
```
192.168.178.12:46281 > 192.168.178.1:53 SYN, MSS 700
192.168.178.1:53 > 192.168.178.12:46281 SYN-ACK, MSS 1460
192.168.178.12:46281 > 192.168.178.1:53 DNSKEY query
192.168.178.1:53 > 192.168.178.12:46281 ACK
```
But no DNS response is delivered to the client. After approximately 5 seconds the client closes the connection.
With MSS 800, the same query succeeds. The response is:
```
192.168.178.1:53 > 192.168.178.12:12536
TCP payload: 726 bytes
IP total length: 778 bytes
```
and the client immediately ACKs and receives the complete 724-byte DNS response.
## Important additional observation
This does **not appear to be an Unbound-specific problem**.
The same behaviour has been observed when testing DNS servers/providers including:
* Google DNS
* Cloudflare DNS
* Quad9
* the local Ziggo modem
The issue therefore appears to be somewhere in the OPNsense/network path handling of TCP DNS rather than the DNS resolver itself.
## Normal TCP segmentation works
I also tested downloading a large file over HTTPS through the same OPNsense installation.
A packet capture showed the remote HTTPS server sending many TCP segments with approximately 688 bytes of TCP payload:
```
78.46.170.2:443 > 192.168.178.12:17455
IP length: 740
TCP payload: 688
```
These packets are received and ACKed normally and the large HTTPS transfer works.
Therefore this does **not** appear to be a general inability of OPNsense/the NIC/network stack to handle TCP segmentation.
The interesting characteristic is that the failure appears to be specific to **TCP DNS traffic (port 53)**.
## Other troubleshooting already performed
The following have already been checked/tested:
* Hardware checksum offloading disabled.
* Hardware TSO/TCP segmentation offload disabled.
* VLAN hardware filtering disabled.
* Other relevant hardware offload settings have already been disabled.
* MSS/normalization has been explicitly tested.
* The failure is reproducible by changing only the MSS normalization value.
* The normal MSS configuration also exhibits the problem with larger DNS responses, so this is not simply a permanently configured MSS=700 issue.
OPNsense's documentation confirms that normalization/scrubbing can modify TCP MSS and perform fragment reassembly, so this seemed relevant to investigate.
## Packet capture demonstrating successful case
With MSS 800:
```
192.168.178.12:12536 > 192.168.178.1:53
DNSKEY rdw.nl
192.168.178.1:53 > 192.168.178.12:12536
IP length 778
TCP payload 726 bytes
DNS response payload 724 bytes
192.168.178.12 > 192.168.178.1
ACK
```
The query completes successfully.
With MSS 700, the handshake and DNS query complete, but the response does not reach the client.
## What I would like help identifying
At this point I suspect a problem somewhere in the OPNsense/PF networking path involving **TCP DNS and packet/segment size**, possibly normalization/scrubbing, state handling, filtering, or another PF/network-stack interaction.
The fact that ordinary HTTPS TCP segmentation works makes this particularly interesting: it seems to be **TCP segmentation/packet-size handling that is specific to TCP/53**, rather than a generic TCP segmentation failure.
I would appreciate guidance on:
1. How to determine exactly where the DNS TCP response is being lost.
2. Whether PF scrub/normalization has any known interaction with TCP DNS responses of this size.
3. Whether there are known OPNsense/pf issues involving TCP port 53 and segment sizes around this range.
4. Which additional packet captures or `pfctl` diagnostics would be most useful to determine whether PF receives, modifies, drops, or fails to forward the DNS response.
I am seeing a reproducible problem with **DNS over TCP through OPNsense**. The failure is strongly correlated with the size of TCP segments/packets.
The problem is not specific to Unbound or to a particular upstream DNS provider.
## Environment
* OPNsense is the gateway/firewall.
* Ziggo modem: `192.168.78.1`
* OPNsense WAN IP: `192.168.178.12`
* WAN interface: `ue0`
* Test query:
`drill -t @192.168.178.1 rdw.nl DNSKEY`
* The DNSKEY response is approximately 724 bytes.
## Reproduction
With a TCP MSS normalization rule applied to the LAN traffic:
* MSS **700** → DNSKEY query fails
* MSS **800** → DNSKEY query succeeds
* MSS **500** → DNSKEY query fails
This is highly reproducible.
At MSS 700, the TCP handshake succeeds and the DNS query is successfully delivered to `192.168.178.1:53`. The client then waits for the DNS response and eventually closes the connection.
Example:
```
192.168.178.12:46281 > 192.168.178.1:53 SYN, MSS 700
192.168.178.1:53 > 192.168.178.12:46281 SYN-ACK, MSS 1460
192.168.178.12:46281 > 192.168.178.1:53 DNSKEY query
192.168.178.1:53 > 192.168.178.12:46281 ACK
```
But no DNS response is delivered to the client. After approximately 5 seconds the client closes the connection.
With MSS 800, the same query succeeds. The response is:
```
192.168.178.1:53 > 192.168.178.12:12536
TCP payload: 726 bytes
IP total length: 778 bytes
```
and the client immediately ACKs and receives the complete 724-byte DNS response.
## Important additional observation
This does **not appear to be an Unbound-specific problem**.
The same behaviour has been observed when testing DNS servers/providers including:
* Google DNS
* Cloudflare DNS
* Quad9
* the local Ziggo modem
The issue therefore appears to be somewhere in the OPNsense/network path handling of TCP DNS rather than the DNS resolver itself.
## Normal TCP segmentation works
I also tested downloading a large file over HTTPS through the same OPNsense installation.
A packet capture showed the remote HTTPS server sending many TCP segments with approximately 688 bytes of TCP payload:
```
78.46.170.2:443 > 192.168.178.12:17455
IP length: 740
TCP payload: 688
```
These packets are received and ACKed normally and the large HTTPS transfer works.
Therefore this does **not** appear to be a general inability of OPNsense/the NIC/network stack to handle TCP segmentation.
The interesting characteristic is that the failure appears to be specific to **TCP DNS traffic (port 53)**.
## Other troubleshooting already performed
The following have already been checked/tested:
* Hardware checksum offloading disabled.
* Hardware TSO/TCP segmentation offload disabled.
* VLAN hardware filtering disabled.
* Other relevant hardware offload settings have already been disabled.
* MSS/normalization has been explicitly tested.
* The failure is reproducible by changing only the MSS normalization value.
* The normal MSS configuration also exhibits the problem with larger DNS responses, so this is not simply a permanently configured MSS=700 issue.
OPNsense's documentation confirms that normalization/scrubbing can modify TCP MSS and perform fragment reassembly, so this seemed relevant to investigate.
## Packet capture demonstrating successful case
With MSS 800:
```
192.168.178.12:12536 > 192.168.178.1:53
DNSKEY rdw.nl
192.168.178.1:53 > 192.168.178.12:12536
IP length 778
TCP payload 726 bytes
DNS response payload 724 bytes
192.168.178.12 > 192.168.178.1
ACK
```
The query completes successfully.
With MSS 700, the handshake and DNS query complete, but the response does not reach the client.
## What I would like help identifying
At this point I suspect a problem somewhere in the OPNsense/PF networking path involving **TCP DNS and packet/segment size**, possibly normalization/scrubbing, state handling, filtering, or another PF/network-stack interaction.
The fact that ordinary HTTPS TCP segmentation works makes this particularly interesting: it seems to be **TCP segmentation/packet-size handling that is specific to TCP/53**, rather than a generic TCP segmentation failure.
I would appreciate guidance on:
1. How to determine exactly where the DNS TCP response is being lost.
2. Whether PF scrub/normalization has any known interaction with TCP DNS responses of this size.
3. Whether there are known OPNsense/pf issues involving TCP port 53 and segment sizes around this range.
4. Which additional packet captures or `pfctl` diagnostics would be most useful to determine whether PF receives, modifies, drops, or fails to forward the DNS response.
#4
General Discussion / Re: [SOLVED] Roku DNS storm is...
Last post by OPNenthu - Today at 10:23:34 AMOh, but I think there might be a wrinkle with how the floating rules expand. One rule in OPNsense could really be several rules in pf, so best to check the ruleset on the backend.
#5
General Discussion / Re: [SOLVED] Roku DNS storm is...
Last post by OPNenthu - Today at 10:17:38 AMQuote from: tangofan on Today at 09:48:43 AMThat "50 per 10s" you set, is this per individual device (e.g. per source ip) or is this across all matches for that rule (so the matches for Roku1 would also count towards the rate limiting of Roku2 and vice versa)?
Going off of the man page description for 'max-pkt-rate', I think it should count for all the clients in the source alias I used. The manual says it measures "packets matching the rule and states created by it," which I interpret this way.
I can say that the earlier Unbound reports corroborated this. While both of the Rokus were actively spamming, the total rate of queries between them was capped at the set rate.
Maybe a dev can confirm this.
#6
26.7 Series / Re: Interfaces: Virtual IPs: S...
Last post by dseven - Today at 10:09:13 AMQuote from: MK4L on August 17, 2026, 11:15:05 PMAnd, yes: Please bring back VIP Mode=Other to the UI.
Maybe I missed it, but I don't believe you have yet explained the purpose of this dummy/fake VIP. Maybe if you could explain, architecturally, what you're trying to do, and how this fake VIP fits into that, another solution can be found.
I still believe that a routed solution is the proper way, though. There's no reason (that I can see) for it not to work, if you stop contorting it with things like multiple default routes.
#7
General Discussion / Re: [SOLVED] Roku DNS storm is...
Last post by tangofan - Today at 09:48:43 AMQuote from: OPNenthu on August 14, 2026, 01:23:26 AMI'm going to call this a win. Been following the issue for some days now and the pf rate limiter is reliably capping the queries from the Roku group to just around 300/min, which corresponds perfectly to the 50 / 10s rate that I set in the rules.
That "50 per 10s" you set, is this per individual device (e.g. per source ip) or is this across all matches for that rule (so the matches for Roku1 would also count towards the rate limiting of Roku2 and vice versa)?
#8
26.7 Series / Re: Interfaces: Virtual IPs: S...
Last post by lmoore - Today at 09:41:11 AMHere's my list of interface assignments.
#9
General Discussion / Re: Can I create locked down w...
Last post by meyergru - Today at 09:28:51 AMPatrick is right. Don't bother with USB adapters on OpnSense, use APs.
As for the router idea: I think you are mixing up concepts here. If the router really acts as a router and does NAT, OpnSense will not be able to discern between devices behind that router, so no. If it can be repurposed as a switch, then in a sense, yes. However, all devices connected to the switch can interact without OpnSense even interfering.
Also, what you can do is limited once the devices have internet access, because traffic might happen on different ports and encrypted while you cannot see what's in it. Complete control is a myth - unless you block everything.
Rules per device is possible, but then again: how do you even identify a specific device? By IP? By MAC? Good luck with either.
As for the router idea: I think you are mixing up concepts here. If the router really acts as a router and does NAT, OpnSense will not be able to discern between devices behind that router, so no. If it can be repurposed as a switch, then in a sense, yes. However, all devices connected to the switch can interact without OpnSense even interfering.
Also, what you can do is limited once the devices have internet access, because traffic might happen on different ports and encrypted while you cannot see what's in it. Complete control is a myth - unless you block everything.
Rules per device is possible, but then again: how do you even identify a specific device? By IP? By MAC? Good luck with either.
#10
26.7 Series / Re: Interfaces: Virtual IPs: S...
Last post by lmoore - Today at 09:21:18 AMQuote from: MK4L on August 17, 2026, 11:12:45 PMbecause there is no such thing as a Bridge interface to use in Firewall/Rules
Verify the bridge interface is enabled
I have set up a transparent firewall using these instructions and it is working for me.
