"Recent posts
#1
26.7 Series / Re: slow dhcp on wan -> broken...
Last post by lmoore - Today at 05:24:00 AMThere are a number of articles relating to net.link.ether.inet.max_age and reducing its value, in particular, to overcome slowness issues.
There is also a patch submission for FreeBSD 16 for the default timeout value to be changed - https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=291100
There is also a patch submission for FreeBSD 16 for the default timeout value to be changed - https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=291100
#2
26.7 Series / OPNsense Protectli boot failur...
Last post by CursedGravity - Today at 03:06:47 AMI am running OPNsense on the FW4B Protectli appliance. The system was previously working normally. My internet just dropped out randomly.
Storage is a ZFS root installation:
zroot
└── ROOT
└── default
The system originally failed to boot with:
Mounting from zfs:zroot/ROOT/default failed with error 5
Retrying for 3 or more seconds...
Initial troubleshooting
I created a verified OPNsense 26.7 VGA amd64 USB image and booted into the live environment.
From the OPNsense live shell:
zpool import
showed the pool was detected and reported:
state: ONLINE
The pool was not initially importable because it reported:
pool was previously in use from another system
the pool can be imported using 'zpool import -f'
ZFS pool checks
I imported the pool read-only:
zpool import -f -o readonly=on zroot
The import succeeded, although mounting datasets failed because the pool was read-only:
cannot mount /zroot: failed to create mountpoint: read-only file system
import was successful, but unable to mount some datasets
After import:
zpool status -v
showed:
state: ONLINE
errors: No known data errors
The boot environment exists:
zfs list
shows:
zroot/ROOT
zroot/ROOT/default
Attempted ZFS rewind/recovery
Because the original import suggested:
recovery is possible, but will result in some data loss
approximately 2 minutes of data must be discarded
recovery can be attempted by executing:
zpool import -F zroot
I attempted:
zpool import -f -F zroot
However, this caused a system panic.
The panic message was:
KDB: enter: panic
panic: zfs(panic): zfs: rt=... adding segment.... overlapping with existing one
Current situation
After the successful read-only import, I rebooted from the internal disk.
The system now gets further into the boot process but stops at:
KDB: enter: panic
db>
Storage is a ZFS root installation:
zroot
└── ROOT
└── default
The system originally failed to boot with:
Mounting from zfs:zroot/ROOT/default failed with error 5
Retrying for 3 or more seconds...
Initial troubleshooting
I created a verified OPNsense 26.7 VGA amd64 USB image and booted into the live environment.
From the OPNsense live shell:
zpool import
showed the pool was detected and reported:
state: ONLINE
The pool was not initially importable because it reported:
pool was previously in use from another system
the pool can be imported using 'zpool import -f'
ZFS pool checks
I imported the pool read-only:
zpool import -f -o readonly=on zroot
The import succeeded, although mounting datasets failed because the pool was read-only:
cannot mount /zroot: failed to create mountpoint: read-only file system
import was successful, but unable to mount some datasets
After import:
zpool status -v
showed:
state: ONLINE
errors: No known data errors
The boot environment exists:
zfs list
shows:
zroot/ROOT
zroot/ROOT/default
Attempted ZFS rewind/recovery
Because the original import suggested:
recovery is possible, but will result in some data loss
approximately 2 minutes of data must be discarded
recovery can be attempted by executing:
zpool import -F zroot
I attempted:
zpool import -f -F zroot
However, this caused a system panic.
The panic message was:
KDB: enter: panic
panic: zfs(panic): zfs: rt=... adding segment.... overlapping with existing one
Current situation
After the successful read-only import, I rebooted from the internal disk.
The system now gets further into the boot process but stops at:
KDB: enter: panic
db>
#3
26.7 Series / Re: Services widget
Last post by AhnHEL - Today at 02:25:22 AM@franco
Patch looks great now, thank you sir.
Patch looks great now, thank you sir.
#4
German - Deutsch / Stop staring at the screen
Last post by yannickb - Today at 01:22:31 AMGirls who are ready for anything - No Selfie
https://fixdim.com
She's genuine and she's near
NEW GIRLS
Courtney
Jada Stevens
Vanessa
Camille Caramel
Mei Minato
Shadow Kitsune
Aiden Ashley
Mia Gag
Pupa
Whitney Wright
Sonya Vibe
Sasha Grey
Anastasia Doll
https://fixdim.com
She's genuine and she's near
NEW GIRLS
Courtney
Jada Stevens
Vanessa
Camille Caramel
Mei Minato
Shadow Kitsune
Aiden Ashley
Mia Gag
Pupa
Whitney Wright
Sonya Vibe
Sasha Grey
Anastasia Doll
#5
26.1, 26,4 Series / Re: IPV6 redirect to unbound D...
Last post by williamjjp - Today at 12:59:41 AMFollowing up on my own post — @OPNenthu was right, and my IPv4 observation was wrong. Posting the correction in case anyone finds this thread later.
Short version: the redirect was working the whole time, but not for the reason I thought. The inverted firewall rule was not the thing passing redirected traffic.
The mechanism is that opnsense translates before it filters. By the time the filter rules are evaluated, a redirected packet's destination is already the redirect target. So the associated pass rule needs to match the target, not the original destination.
My IPv4 filter rule was destination = !127.0.0.1, port 53, on the interface group. That excludes precisely the packets it was supposed to be passing. What it actually matched was port 53 traffic aimed at my own local addresses — clients querying the firewall's LAN IP directly — which is exactly the traffic the NAT rule deliberately skips. The redirected packets were being passed further down by my ordinary allow-any LAN rule.
Confirmed with logging. Pointing a client at an external resolver produced an rdr line in the firewall log, and the query showed up in Unbound as expected — but there was no corresponding pass line from my manual rule, which had logging enabled. It was never matching.
Why IPv6 looked different: same construction, different outcome. The IPv4 target is 127.0.0.1, which falls outside the negated set, so the inverted rule matched and looked load-bearing. The IPv6 target is a ULA VIP, which falls inside the negated set, so the same rule visibly failed to match. One mechanism, two results — not an inconsistency in OPNsense.
I also suspect what I read as "unchecking invert breaks the IPv4 redirect" was actually the loss of DNS to the firewall's own LAN address. Clients pointed at the gateway for DNS would break in a way that looks identical to a broken redirect from the client side.
The fix was to stop hand-writing the filter rules entirely: set the NAT rule's Firewall rule option to Register and let OPNsense generate the associated rule (destination = the redirect target, not inverted). Verified working on both protocols now, with no asymmetry between them.
@meyergru's point stands and is the one genuine IPv4/IPv6 difference here — the IPv6 redirect target has to be routable, hence a ULA VIP rather than ::1. I had that part right already, which is why the v6 side worked.
Apologies for the noise, and thanks to both of you for the pushback.
Short version: the redirect was working the whole time, but not for the reason I thought. The inverted firewall rule was not the thing passing redirected traffic.
The mechanism is that opnsense translates before it filters. By the time the filter rules are evaluated, a redirected packet's destination is already the redirect target. So the associated pass rule needs to match the target, not the original destination.
My IPv4 filter rule was destination = !127.0.0.1, port 53, on the interface group. That excludes precisely the packets it was supposed to be passing. What it actually matched was port 53 traffic aimed at my own local addresses — clients querying the firewall's LAN IP directly — which is exactly the traffic the NAT rule deliberately skips. The redirected packets were being passed further down by my ordinary allow-any LAN rule.
Confirmed with logging. Pointing a client at an external resolver produced an rdr line in the firewall log, and the query showed up in Unbound as expected — but there was no corresponding pass line from my manual rule, which had logging enabled. It was never matching.
Why IPv6 looked different: same construction, different outcome. The IPv4 target is 127.0.0.1, which falls outside the negated set, so the inverted rule matched and looked load-bearing. The IPv6 target is a ULA VIP, which falls inside the negated set, so the same rule visibly failed to match. One mechanism, two results — not an inconsistency in OPNsense.
I also suspect what I read as "unchecking invert breaks the IPv4 redirect" was actually the loss of DNS to the firewall's own LAN address. Clients pointed at the gateway for DNS would break in a way that looks identical to a broken redirect from the client side.
The fix was to stop hand-writing the filter rules entirely: set the NAT rule's Firewall rule option to Register and let OPNsense generate the associated rule (destination = the redirect target, not inverted). Verified working on both protocols now, with no asymmetry between them.
@meyergru's point stands and is the one genuine IPv4/IPv6 difference here — the IPv6 redirect target has to be routable, hence a ULA VIP rather than ::1. I had that part right already, which is why the v6 side worked.
Apologies for the noise, and thanks to both of you for the pushback.
#6
26.7 Series / 26.7.1_1 - Alias not working -...
Last post by inetjnky - Today at 12:08:53 AMI haven't tested existing aliases, only a new Alias I created to block all internet traffic from the IPs of the LG OLED TVs.
Alias Created and enabled. Name LG_TVs, Type: Host(s), Content: 192.168.107.6, 192.168.107.7
Applied, powered off TVs killed all Firewall - Diagnostics - States for both IPs. Powered TVs back on and verified I am able to access internet.
Used Claude to assist with troubleshooting.
SSH into Opensense box:
jason@opnsense:~ $ sudo pfctl -sr | grep -n "107.6\|107.7\|LG_TVs"
Password:
242:block drop in quick on vlan02 inet from <LG_TVs> to ! <PrivateNetworks> label "c61d8481-5bf4-4f08-b9eb-bd616fbae7e5"
243:block drop in quick on vlan02 inet6 from <LG_TVs> to ! <PrivateNetworks> label "c61d8481-5bf4-4f08-b9eb-bd616fbae7e5"
The rule is loaded in the live kernel ruleset, correctly as block drop in quick ... from <LG_TVs> to ! <PrivateNetworks> on vlan02. So it's not a stale-apply issue after all — the block rule genuinely exists in pf, in quick form, exactly as configured.
But it's at line 242/243 — quite far down in the ruleset. The states showed traffic matching "Allow access only to Internet" instead. Since pf evaluates top-to-bottom and stops at first quick match, that means the "Allow access only to Internet" rule for IOT network must be sitting at a lower line number (earlier in the ruleset) than 242, even though the OPNsense GUI displays it visually beneath the block rule on the interface tab.
jason@opnsense:~ $ sudo pfctl -sr | grep -n "Allow access only to Internet\|IOT network"
jason@opnsense:~ $ sudo pfctl -sr | grep -n "vlan02.*inet.*IOT network\|quick on vlan02"
109:pass in log quick on vlan02 inet proto udp from any port = bootpc to 255.255.255.255 port = bootps keep state label "03b1df4bf62ce677123044d57e8e60b7"
110:pass in log quick on vlan02 proto udp from any port = bootpc to (self) port = bootps keep state label "4749c8cd166b293d17735bbe5fafeba7"
111:pass out log quick on vlan02 proto udp from (self) port = bootps to any port = bootpc keep state label "4fa69e1fc6f690d3cf45e05e517f2448"
112:pass in log quick on vlan02 inet6 proto udp from fe80::/10 to fe80::/10 port = dhcpv6-client keep state label "939d681febd9e3466ef8a12b27d64c0f"
113:pass in log quick on vlan02 inet6 proto udp from fe80::/10 to ff02::/16 port = dhcpv6-client keep state label "939d681febd9e3466ef8a12b27d64c0f"
114:pass in log quick on vlan02 inet6 proto udp from fe80::/10 to ff02::/16 port = dhcpv6-server keep state label "4821d7ce2e22b7f16097ae6dc6d1daa2"
115:pass in log quick on vlan02 inet6 proto udp from ff02::/16 to fe80::/10 port = dhcpv6-server keep state label "c63c997e3cc96fd90d29d8b05686b19f"
116:pass in log quick on vlan02 inet6 proto udp from fe80::/10 to (self) port = dhcpv6-client keep state label "14c2a36dc5849b4ff7d2f27d17569718"
117:pass out log quick on vlan02 inet6 proto udp from (self) port = dhcpv6-server to fe80::/10 keep state label "a3228c8a3726d15188b7ff67041c14cd"
207:block drop in log quick on vlan02 inet6 from any to <crowdsec_blacklists> label "a3589517-dc02-4853-9298-18a02cc8bf61"
214:block drop in log quick on vlan02 inet from any to <crowdsec_blacklists> label "1c0d57bf-c8ee-4e67-be93-331a33069059"
236:pass in quick on vlan02 inet proto tcp from (vlan02:network) to (vlan02) port = domain flags S/SA keep state label "bac5a17f-a0f6-4b76-ac06-2fc6db7f797b"
237:pass in quick on vlan02 inet proto udp from (vlan02:network) to (vlan02) port = domain keep state label "bac5a17f-a0f6-4b76-ac06-2fc6db7f797b"
238:pass in quick on vlan02 inet6 proto tcp from (vlan02:network) to (vlan02) port = domain flags S/SA keep state label "bac5a17f-a0f6-4b76-ac06-2fc6db7f797b"
239:pass in quick on vlan02 inet6 proto tcp from fe80::/10 to (vlan02) port = domain flags S/SA keep state label "bac5a17f-a0f6-4b76-ac06-2fc6db7f797b"
240:pass in quick on vlan02 inet6 proto udp from (vlan02:network) to (vlan02) port = domain keep state label "bac5a17f-a0f6-4b76-ac06-2fc6db7f797b"
241:pass in quick on vlan02 inet6 proto udp from fe80::/10 to (vlan02) port = domain keep state label "bac5a17f-a0f6-4b76-ac06-2fc6db7f797b"
242:block drop in quick on vlan02 inet from <LG_TVs> to ! <PrivateNetworks> label "c61d8481-5bf4-4f08-b9eb-bd616fbae7e5"
243:block drop in quick on vlan02 inet6 from <LG_TVs> to ! <PrivateNetworks> label "c61d8481-5bf4-4f08-b9eb-bd616fbae7e5"
244:pass in quick on vlan02 inet proto tcp from (vlan02:network) to <IPCAM_MGMT> flags S/SA keep state label "e909a6be-6b1e-49f8-b05c-12f7d5830140"
245:pass in quick on vlan02 inet proto udp from (vlan02:network) to <IPCAM_MGMT> keep state label "e909a6be-6b1e-49f8-b05c-12f7d5830140"
246:pass in quick on vlan02 inet6 proto tcp from (vlan02:network) to <IPCAM_MGMT> flags S/SA keep state label "e909a6be-6b1e-49f8-b05c-12f7d5830140"
247:pass in quick on vlan02 inet6 proto tcp from fe80::/10 to <IPCAM_MGMT> flags S/SA keep state label "e909a6be-6b1e-49f8-b05c-12f7d5830140"
248:pass in quick on vlan02 inet6 proto udp from (vlan02:network) to <IPCAM_MGMT> keep state label "e909a6be-6b1e-49f8-b05c-12f7d5830140"
249:pass in quick on vlan02 inet6 proto udp from fe80::/10 to <IPCAM_MGMT> keep state label "e909a6be-6b1e-49f8-b05c-12f7d5830140"
298:pass in quick on vlan02 inet from (vlan02:network) to <NAS_STORAGE> flags S/SA keep state label "3509ce2e-28ea-451a-b149-e96b89d087e5"
299:pass in quick on vlan02 inet6 from (vlan02:network) to <NAS_STORAGE> flags S/SA keep state label "3509ce2e-28ea-451a-b149-e96b89d087e5"
300:pass in quick on vlan02 inet6 from fe80::/10 to <NAS_STORAGE> flags S/SA keep state label "3509ce2e-28ea-451a-b149-e96b89d087e5"
301:pass in quick on vlan02 inet from (vlan02:network) to <ProxmoxVMCTNetwork> flags S/SA keep state label "de0c65c6-e86f-43e4-a6a9-ec5246ca85da"
302:pass in quick on vlan02 inet6 from (vlan02:network) to <ProxmoxVMCTNetwork> flags S/SA keep state label "de0c65c6-e86f-43e4-a6a9-ec5246ca85da"
303:pass in quick on vlan02 inet6 from fe80::/10 to <ProxmoxVMCTNetwork> flags S/SA keep state label "de0c65c6-e86f-43e4-a6a9-ec5246ca85da"
383:pass in quick on vlan02 inet from (vlan02:network) to 192.168.108.20 flags S/SA keep state label "83ff2c9e-0951-43e5-a083-2e33e7ec071c"
384:pass in quick on vlan02 inet from 192.168.107.24 to (vlan01:network) flags S/SA keep state label "58847e5e-f396-4b5a-964a-7d41334101a2"
385:pass in quick on vlan02 inet from (vlan02:network) to ! <PrivateNetworks> flags S/SA keep state label "65d5bb0a-954a-495d-ae36-bb2423f804bf"
386:pass in quick on vlan02 inet6 from (vlan02:network) to ! <PrivateNetworks> flags S/SA keep state label "65d5bb0a-954a-495d-ae36-bb2423f804bf"
387:pass in quick on vlan02 inet6 from fe80::/10 to ! <PrivateNetworks> flags S/SA keep state label "65d5bb0a-954a-495d-ae36-bb2423f804bf"
jason@opnsense:~ $ sudo pfctl -sr | grep -n "vlan02"
3:block drop in log on vlan02 inet6 from fe80::aab8:e0ff:fe02:43b to any
12:block drop in log on ! vlan02 inet6 from ::/64 to any
21:block drop in log on ! vlan02 inet from 192.168.107.0/24 to any
109:pass in log quick on vlan02 inet proto udp from any port = bootpc to 255.255.255.255 port = bootps keep state label "03b1df4bf62ce677123044d57e8e60b7"
110:pass in log quick on vlan02 proto udp from any port = bootpc to (self) port = bootps keep state label "4749c8cd166b293d17735bbe5fafeba7"
111:pass out log quick on vlan02 proto udp from (self) port = bootps to any port = bootpc keep state label "4fa69e1fc6f690d3cf45e05e517f2448"
112:pass in log quick on vlan02 inet6 proto udp from fe80::/10 to fe80::/10 port = dhcpv6-client keep state label "939d681febd9e3466ef8a12b27d64c0f"
113:pass in log quick on vlan02 inet6 proto udp from fe80::/10 to ff02::/16 port = dhcpv6-client keep state label "939d681febd9e3466ef8a12b27d64c0f"
114:pass in log quick on vlan02 inet6 proto udp from fe80::/10 to ff02::/16 port = dhcpv6-server keep state label "4821d7ce2e22b7f16097ae6dc6d1daa2"
115:pass in log quick on vlan02 inet6 proto udp from ff02::/16 to fe80::/10 port = dhcpv6-server keep state label "c63c997e3cc96fd90d29d8b05686b19f"
116:pass in log quick on vlan02 inet6 proto udp from fe80::/10 to (self) port = dhcpv6-client keep state label "14c2a36dc5849b4ff7d2f27d17569718"
117:pass out log quick on vlan02 inet6 proto udp from (self) port = dhcpv6-server to fe80::/10 keep state label "a3228c8a3726d15188b7ff67041c14cd"
207:block drop in log quick on vlan02 inet6 from any to <crowdsec_blacklists> label "a3589517-dc02-4853-9298-18a02cc8bf61"
214:block drop in log quick on vlan02 inet from any to <crowdsec_blacklists> label "1c0d57bf-c8ee-4e67-be93-331a33069059"
236:pass in quick on vlan02 inet proto tcp from (vlan02:network) to (vlan02) port = domain flags S/SA keep state label "bac5a17f-a0f6-4b76-ac06-2fc6db7f797b"
237:pass in quick on vlan02 inet proto udp from (vlan02:network) to (vlan02) port = domain keep state label "bac5a17f-a0f6-4b76-ac06-2fc6db7f797b"
238:pass in quick on vlan02 inet6 proto tcp from (vlan02:network) to (vlan02) port = domain flags S/SA keep state label "bac5a17f-a0f6-4b76-ac06-2fc6db7f797b"
239:pass in quick on vlan02 inet6 proto tcp from fe80::/10 to (vlan02) port = domain flags S/SA keep state label "bac5a17f-a0f6-4b76-ac06-2fc6db7f797b"
240:pass in quick on vlan02 inet6 proto udp from (vlan02:network) to (vlan02) port = domain keep state label "bac5a17f-a0f6-4b76-ac06-2fc6db7f797b"
241:pass in quick on vlan02 inet6 proto udp from fe80::/10 to (vlan02) port = domain keep state label "bac5a17f-a0f6-4b76-ac06-2fc6db7f797b"
242:block drop in quick on vlan02 inet from <LG_TVs> to ! <PrivateNetworks> label "c61d8481-5bf4-4f08-b9eb-bd616fbae7e5"
243:block drop in quick on vlan02 inet6 from <LG_TVs> to ! <PrivateNetworks> label "c61d8481-5bf4-4f08-b9eb-bd616fbae7e5"
244:pass in quick on vlan02 inet proto tcp from (vlan02:network) to <IPCAM_MGMT> flags S/SA keep state label "e909a6be-6b1e-49f8-b05c-12f7d5830140"
245:pass in quick on vlan02 inet proto udp from (vlan02:network) to <IPCAM_MGMT> keep state label "e909a6be-6b1e-49f8-b05c-12f7d5830140"
246:pass in quick on vlan02 inet6 proto tcp from (vlan02:network) to <IPCAM_MGMT> flags S/SA keep state label "e909a6be-6b1e-49f8-b05c-12f7d5830140"
247:pass in quick on vlan02 inet6 proto tcp from fe80::/10 to <IPCAM_MGMT> flags S/SA keep state label "e909a6be-6b1e-49f8-b05c-12f7d5830140"
248:pass in quick on vlan02 inet6 proto udp from (vlan02:network) to <IPCAM_MGMT> keep state label "e909a6be-6b1e-49f8-b05c-12f7d5830140"
249:pass in quick on vlan02 inet6 proto udp from fe80::/10 to <IPCAM_MGMT> keep state label "e909a6be-6b1e-49f8-b05c-12f7d5830140"
284:pass in quick on vlan01 inet from <NAS_STORAGE> to (vlan02) flags S/SA keep state label "7bf91b41-e226-43b4-89bc-c3bd35de1186"
285:pass in quick on vlan01 inet6 from <NAS_STORAGE> to (vlan02) flags S/SA keep state label "7bf91b41-e226-43b4-89bc-c3bd35de1186"
298:pass in quick on vlan02 inet from (vlan02:network) to <NAS_STORAGE> flags S/SA keep state label "3509ce2e-28ea-451a-b149-e96b89d087e5"
299:pass in quick on vlan02 inet6 from (vlan02:network) to <NAS_STORAGE> flags S/SA keep state label "3509ce2e-28ea-451a-b149-e96b89d087e5"
300:pass in quick on vlan02 inet6 from fe80::/10 to <NAS_STORAGE> flags S/SA keep state label "3509ce2e-28ea-451a-b149-e96b89d087e5"
301:pass in quick on vlan02 inet from (vlan02:network) to <ProxmoxVMCTNetwork> flags S/SA keep state label "de0c65c6-e86f-43e4-a6a9-ec5246ca85da"
302:pass in quick on vlan02 inet6 from (vlan02:network) to <ProxmoxVMCTNetwork> flags S/SA keep state label "de0c65c6-e86f-43e4-a6a9-ec5246ca85da"
303:pass in quick on vlan02 inet6 from fe80::/10 to <ProxmoxVMCTNetwork> flags S/SA keep state label "de0c65c6-e86f-43e4-a6a9-ec5246ca85da"
354:pass in quick on vlan07 inet from <ProxmoxVMCTNetwork> to (vlan02) flags S/SA keep state label "5116012b-f854-4419-a6c1-0c32e9e09a01"
355:pass in quick on vlan07 inet6 from <ProxmoxVMCTNetwork> to (vlan02) flags S/SA keep state label "5116012b-f854-4419-a6c1-0c32e9e09a01"
383:pass in quick on vlan02 inet from (vlan02:network) to 192.168.108.20 flags S/SA keep state label "83ff2c9e-0951-43e5-a083-2e33e7ec071c"
384:pass in quick on vlan02 inet from 192.168.107.24 to (vlan01:network) flags S/SA keep state label "58847e5e-f396-4b5a-964a-7d41334101a2"
385:pass in quick on vlan02 inet from (vlan02:network) to ! <PrivateNetworks> flags S/SA keep state label "65d5bb0a-954a-495d-ae36-bb2423f804bf"
386:pass in quick on vlan02 inet6 from (vlan02:network) to ! <PrivateNetworks> flags S/SA keep state label "65d5bb0a-954a-495d-ae36-bb2423f804bf"
387:pass in quick on vlan02 inet6 from fe80::/10 to ! <PrivateNetworks> flags S/SA keep state label "65d5bb0a-954a-495d-ae36-bb2423f804bf"
The Block LG_TVs rule sits at line 242/243 — well before the general Allow access only to Internet rule at line 385/386, for both IPv4 and IPv6. Since pf is quick and evaluates top-down, any traffic sourced from LG_TVs will now hit the block at line 242 and stop right there — it will never reach line 385.
jason@opnsense:~ $ sudo pfctl -t LG_TVs -T show
The LG_TVs table is completely empty in the live kernel, despite the rule referencing it being loaded correctly at line 242/243. This is exactly why traffic sails right past the block rule (an empty table matches nothing) and falls through to the general allow rule further down. This is the actual root cause. The fix,force a manual table load first, to test.
jason@opnsense:~ $ sudo pfctl -t LG_TVs -T add 192.168.107.6
1/1 addresses added.
jason@opnsense:~ $ sudo pfctl -t LG_TVs -T add 192.168.107.7
sudo pfctl -t LG_TVs -T show1/1 addresses added.
jason@opnsense:~ $ sudo pfctl -t LG_TVs -T show
192.168.107.6
192.168.107.7
This should now show both IPs. If it does, kill the states again and test the TVs immediately — if they get blocked now, we've fully confirmed the table-sync issue is the culprit (though this manual add won't survive a reboot/reload, so it's just for confirmation, not the permanent fix). The next command forces OPNsense to fully regenerate and reload the entire pf ruleset and all alias tables from the current config, which should definitely repopulate LG_TVs. Then check the table again.
jason@opnsense:~ $ sudo /usr/local/etc/rc.filter_configure
Configuring firewall.......done.
jason@opnsense:~ $ sudo pfctl -t LG_TVs -T show
192.168.107.6
192.168.107.7
jason@opnsense:~ $
Both IPs are now in the table. This confirms the theory completely: the table syncing from the alias definition to the running pf table was broken, and manually adding them fixed the immediate symptom.
Alias Created and enabled. Name LG_TVs, Type: Host(s), Content: 192.168.107.6, 192.168.107.7
Applied, powered off TVs killed all Firewall - Diagnostics - States for both IPs. Powered TVs back on and verified I am able to access internet.
Used Claude to assist with troubleshooting.
SSH into Opensense box:
jason@opnsense:~ $ sudo pfctl -sr | grep -n "107.6\|107.7\|LG_TVs"
Password:
242:block drop in quick on vlan02 inet from <LG_TVs> to ! <PrivateNetworks> label "c61d8481-5bf4-4f08-b9eb-bd616fbae7e5"
243:block drop in quick on vlan02 inet6 from <LG_TVs> to ! <PrivateNetworks> label "c61d8481-5bf4-4f08-b9eb-bd616fbae7e5"
The rule is loaded in the live kernel ruleset, correctly as block drop in quick ... from <LG_TVs> to ! <PrivateNetworks> on vlan02. So it's not a stale-apply issue after all — the block rule genuinely exists in pf, in quick form, exactly as configured.
But it's at line 242/243 — quite far down in the ruleset. The states showed traffic matching "Allow access only to Internet" instead. Since pf evaluates top-to-bottom and stops at first quick match, that means the "Allow access only to Internet" rule for IOT network must be sitting at a lower line number (earlier in the ruleset) than 242, even though the OPNsense GUI displays it visually beneath the block rule on the interface tab.
jason@opnsense:~ $ sudo pfctl -sr | grep -n "Allow access only to Internet\|IOT network"
jason@opnsense:~ $ sudo pfctl -sr | grep -n "vlan02.*inet.*IOT network\|quick on vlan02"
109:pass in log quick on vlan02 inet proto udp from any port = bootpc to 255.255.255.255 port = bootps keep state label "03b1df4bf62ce677123044d57e8e60b7"
110:pass in log quick on vlan02 proto udp from any port = bootpc to (self) port = bootps keep state label "4749c8cd166b293d17735bbe5fafeba7"
111:pass out log quick on vlan02 proto udp from (self) port = bootps to any port = bootpc keep state label "4fa69e1fc6f690d3cf45e05e517f2448"
112:pass in log quick on vlan02 inet6 proto udp from fe80::/10 to fe80::/10 port = dhcpv6-client keep state label "939d681febd9e3466ef8a12b27d64c0f"
113:pass in log quick on vlan02 inet6 proto udp from fe80::/10 to ff02::/16 port = dhcpv6-client keep state label "939d681febd9e3466ef8a12b27d64c0f"
114:pass in log quick on vlan02 inet6 proto udp from fe80::/10 to ff02::/16 port = dhcpv6-server keep state label "4821d7ce2e22b7f16097ae6dc6d1daa2"
115:pass in log quick on vlan02 inet6 proto udp from ff02::/16 to fe80::/10 port = dhcpv6-server keep state label "c63c997e3cc96fd90d29d8b05686b19f"
116:pass in log quick on vlan02 inet6 proto udp from fe80::/10 to (self) port = dhcpv6-client keep state label "14c2a36dc5849b4ff7d2f27d17569718"
117:pass out log quick on vlan02 inet6 proto udp from (self) port = dhcpv6-server to fe80::/10 keep state label "a3228c8a3726d15188b7ff67041c14cd"
207:block drop in log quick on vlan02 inet6 from any to <crowdsec_blacklists> label "a3589517-dc02-4853-9298-18a02cc8bf61"
214:block drop in log quick on vlan02 inet from any to <crowdsec_blacklists> label "1c0d57bf-c8ee-4e67-be93-331a33069059"
236:pass in quick on vlan02 inet proto tcp from (vlan02:network) to (vlan02) port = domain flags S/SA keep state label "bac5a17f-a0f6-4b76-ac06-2fc6db7f797b"
237:pass in quick on vlan02 inet proto udp from (vlan02:network) to (vlan02) port = domain keep state label "bac5a17f-a0f6-4b76-ac06-2fc6db7f797b"
238:pass in quick on vlan02 inet6 proto tcp from (vlan02:network) to (vlan02) port = domain flags S/SA keep state label "bac5a17f-a0f6-4b76-ac06-2fc6db7f797b"
239:pass in quick on vlan02 inet6 proto tcp from fe80::/10 to (vlan02) port = domain flags S/SA keep state label "bac5a17f-a0f6-4b76-ac06-2fc6db7f797b"
240:pass in quick on vlan02 inet6 proto udp from (vlan02:network) to (vlan02) port = domain keep state label "bac5a17f-a0f6-4b76-ac06-2fc6db7f797b"
241:pass in quick on vlan02 inet6 proto udp from fe80::/10 to (vlan02) port = domain keep state label "bac5a17f-a0f6-4b76-ac06-2fc6db7f797b"
242:block drop in quick on vlan02 inet from <LG_TVs> to ! <PrivateNetworks> label "c61d8481-5bf4-4f08-b9eb-bd616fbae7e5"
243:block drop in quick on vlan02 inet6 from <LG_TVs> to ! <PrivateNetworks> label "c61d8481-5bf4-4f08-b9eb-bd616fbae7e5"
244:pass in quick on vlan02 inet proto tcp from (vlan02:network) to <IPCAM_MGMT> flags S/SA keep state label "e909a6be-6b1e-49f8-b05c-12f7d5830140"
245:pass in quick on vlan02 inet proto udp from (vlan02:network) to <IPCAM_MGMT> keep state label "e909a6be-6b1e-49f8-b05c-12f7d5830140"
246:pass in quick on vlan02 inet6 proto tcp from (vlan02:network) to <IPCAM_MGMT> flags S/SA keep state label "e909a6be-6b1e-49f8-b05c-12f7d5830140"
247:pass in quick on vlan02 inet6 proto tcp from fe80::/10 to <IPCAM_MGMT> flags S/SA keep state label "e909a6be-6b1e-49f8-b05c-12f7d5830140"
248:pass in quick on vlan02 inet6 proto udp from (vlan02:network) to <IPCAM_MGMT> keep state label "e909a6be-6b1e-49f8-b05c-12f7d5830140"
249:pass in quick on vlan02 inet6 proto udp from fe80::/10 to <IPCAM_MGMT> keep state label "e909a6be-6b1e-49f8-b05c-12f7d5830140"
298:pass in quick on vlan02 inet from (vlan02:network) to <NAS_STORAGE> flags S/SA keep state label "3509ce2e-28ea-451a-b149-e96b89d087e5"
299:pass in quick on vlan02 inet6 from (vlan02:network) to <NAS_STORAGE> flags S/SA keep state label "3509ce2e-28ea-451a-b149-e96b89d087e5"
300:pass in quick on vlan02 inet6 from fe80::/10 to <NAS_STORAGE> flags S/SA keep state label "3509ce2e-28ea-451a-b149-e96b89d087e5"
301:pass in quick on vlan02 inet from (vlan02:network) to <ProxmoxVMCTNetwork> flags S/SA keep state label "de0c65c6-e86f-43e4-a6a9-ec5246ca85da"
302:pass in quick on vlan02 inet6 from (vlan02:network) to <ProxmoxVMCTNetwork> flags S/SA keep state label "de0c65c6-e86f-43e4-a6a9-ec5246ca85da"
303:pass in quick on vlan02 inet6 from fe80::/10 to <ProxmoxVMCTNetwork> flags S/SA keep state label "de0c65c6-e86f-43e4-a6a9-ec5246ca85da"
383:pass in quick on vlan02 inet from (vlan02:network) to 192.168.108.20 flags S/SA keep state label "83ff2c9e-0951-43e5-a083-2e33e7ec071c"
384:pass in quick on vlan02 inet from 192.168.107.24 to (vlan01:network) flags S/SA keep state label "58847e5e-f396-4b5a-964a-7d41334101a2"
385:pass in quick on vlan02 inet from (vlan02:network) to ! <PrivateNetworks> flags S/SA keep state label "65d5bb0a-954a-495d-ae36-bb2423f804bf"
386:pass in quick on vlan02 inet6 from (vlan02:network) to ! <PrivateNetworks> flags S/SA keep state label "65d5bb0a-954a-495d-ae36-bb2423f804bf"
387:pass in quick on vlan02 inet6 from fe80::/10 to ! <PrivateNetworks> flags S/SA keep state label "65d5bb0a-954a-495d-ae36-bb2423f804bf"
jason@opnsense:~ $ sudo pfctl -sr | grep -n "vlan02"
3:block drop in log on vlan02 inet6 from fe80::aab8:e0ff:fe02:43b to any
12:block drop in log on ! vlan02 inet6 from ::/64 to any
21:block drop in log on ! vlan02 inet from 192.168.107.0/24 to any
109:pass in log quick on vlan02 inet proto udp from any port = bootpc to 255.255.255.255 port = bootps keep state label "03b1df4bf62ce677123044d57e8e60b7"
110:pass in log quick on vlan02 proto udp from any port = bootpc to (self) port = bootps keep state label "4749c8cd166b293d17735bbe5fafeba7"
111:pass out log quick on vlan02 proto udp from (self) port = bootps to any port = bootpc keep state label "4fa69e1fc6f690d3cf45e05e517f2448"
112:pass in log quick on vlan02 inet6 proto udp from fe80::/10 to fe80::/10 port = dhcpv6-client keep state label "939d681febd9e3466ef8a12b27d64c0f"
113:pass in log quick on vlan02 inet6 proto udp from fe80::/10 to ff02::/16 port = dhcpv6-client keep state label "939d681febd9e3466ef8a12b27d64c0f"
114:pass in log quick on vlan02 inet6 proto udp from fe80::/10 to ff02::/16 port = dhcpv6-server keep state label "4821d7ce2e22b7f16097ae6dc6d1daa2"
115:pass in log quick on vlan02 inet6 proto udp from ff02::/16 to fe80::/10 port = dhcpv6-server keep state label "c63c997e3cc96fd90d29d8b05686b19f"
116:pass in log quick on vlan02 inet6 proto udp from fe80::/10 to (self) port = dhcpv6-client keep state label "14c2a36dc5849b4ff7d2f27d17569718"
117:pass out log quick on vlan02 inet6 proto udp from (self) port = dhcpv6-server to fe80::/10 keep state label "a3228c8a3726d15188b7ff67041c14cd"
207:block drop in log quick on vlan02 inet6 from any to <crowdsec_blacklists> label "a3589517-dc02-4853-9298-18a02cc8bf61"
214:block drop in log quick on vlan02 inet from any to <crowdsec_blacklists> label "1c0d57bf-c8ee-4e67-be93-331a33069059"
236:pass in quick on vlan02 inet proto tcp from (vlan02:network) to (vlan02) port = domain flags S/SA keep state label "bac5a17f-a0f6-4b76-ac06-2fc6db7f797b"
237:pass in quick on vlan02 inet proto udp from (vlan02:network) to (vlan02) port = domain keep state label "bac5a17f-a0f6-4b76-ac06-2fc6db7f797b"
238:pass in quick on vlan02 inet6 proto tcp from (vlan02:network) to (vlan02) port = domain flags S/SA keep state label "bac5a17f-a0f6-4b76-ac06-2fc6db7f797b"
239:pass in quick on vlan02 inet6 proto tcp from fe80::/10 to (vlan02) port = domain flags S/SA keep state label "bac5a17f-a0f6-4b76-ac06-2fc6db7f797b"
240:pass in quick on vlan02 inet6 proto udp from (vlan02:network) to (vlan02) port = domain keep state label "bac5a17f-a0f6-4b76-ac06-2fc6db7f797b"
241:pass in quick on vlan02 inet6 proto udp from fe80::/10 to (vlan02) port = domain keep state label "bac5a17f-a0f6-4b76-ac06-2fc6db7f797b"
242:block drop in quick on vlan02 inet from <LG_TVs> to ! <PrivateNetworks> label "c61d8481-5bf4-4f08-b9eb-bd616fbae7e5"
243:block drop in quick on vlan02 inet6 from <LG_TVs> to ! <PrivateNetworks> label "c61d8481-5bf4-4f08-b9eb-bd616fbae7e5"
244:pass in quick on vlan02 inet proto tcp from (vlan02:network) to <IPCAM_MGMT> flags S/SA keep state label "e909a6be-6b1e-49f8-b05c-12f7d5830140"
245:pass in quick on vlan02 inet proto udp from (vlan02:network) to <IPCAM_MGMT> keep state label "e909a6be-6b1e-49f8-b05c-12f7d5830140"
246:pass in quick on vlan02 inet6 proto tcp from (vlan02:network) to <IPCAM_MGMT> flags S/SA keep state label "e909a6be-6b1e-49f8-b05c-12f7d5830140"
247:pass in quick on vlan02 inet6 proto tcp from fe80::/10 to <IPCAM_MGMT> flags S/SA keep state label "e909a6be-6b1e-49f8-b05c-12f7d5830140"
248:pass in quick on vlan02 inet6 proto udp from (vlan02:network) to <IPCAM_MGMT> keep state label "e909a6be-6b1e-49f8-b05c-12f7d5830140"
249:pass in quick on vlan02 inet6 proto udp from fe80::/10 to <IPCAM_MGMT> keep state label "e909a6be-6b1e-49f8-b05c-12f7d5830140"
284:pass in quick on vlan01 inet from <NAS_STORAGE> to (vlan02) flags S/SA keep state label "7bf91b41-e226-43b4-89bc-c3bd35de1186"
285:pass in quick on vlan01 inet6 from <NAS_STORAGE> to (vlan02) flags S/SA keep state label "7bf91b41-e226-43b4-89bc-c3bd35de1186"
298:pass in quick on vlan02 inet from (vlan02:network) to <NAS_STORAGE> flags S/SA keep state label "3509ce2e-28ea-451a-b149-e96b89d087e5"
299:pass in quick on vlan02 inet6 from (vlan02:network) to <NAS_STORAGE> flags S/SA keep state label "3509ce2e-28ea-451a-b149-e96b89d087e5"
300:pass in quick on vlan02 inet6 from fe80::/10 to <NAS_STORAGE> flags S/SA keep state label "3509ce2e-28ea-451a-b149-e96b89d087e5"
301:pass in quick on vlan02 inet from (vlan02:network) to <ProxmoxVMCTNetwork> flags S/SA keep state label "de0c65c6-e86f-43e4-a6a9-ec5246ca85da"
302:pass in quick on vlan02 inet6 from (vlan02:network) to <ProxmoxVMCTNetwork> flags S/SA keep state label "de0c65c6-e86f-43e4-a6a9-ec5246ca85da"
303:pass in quick on vlan02 inet6 from fe80::/10 to <ProxmoxVMCTNetwork> flags S/SA keep state label "de0c65c6-e86f-43e4-a6a9-ec5246ca85da"
354:pass in quick on vlan07 inet from <ProxmoxVMCTNetwork> to (vlan02) flags S/SA keep state label "5116012b-f854-4419-a6c1-0c32e9e09a01"
355:pass in quick on vlan07 inet6 from <ProxmoxVMCTNetwork> to (vlan02) flags S/SA keep state label "5116012b-f854-4419-a6c1-0c32e9e09a01"
383:pass in quick on vlan02 inet from (vlan02:network) to 192.168.108.20 flags S/SA keep state label "83ff2c9e-0951-43e5-a083-2e33e7ec071c"
384:pass in quick on vlan02 inet from 192.168.107.24 to (vlan01:network) flags S/SA keep state label "58847e5e-f396-4b5a-964a-7d41334101a2"
385:pass in quick on vlan02 inet from (vlan02:network) to ! <PrivateNetworks> flags S/SA keep state label "65d5bb0a-954a-495d-ae36-bb2423f804bf"
386:pass in quick on vlan02 inet6 from (vlan02:network) to ! <PrivateNetworks> flags S/SA keep state label "65d5bb0a-954a-495d-ae36-bb2423f804bf"
387:pass in quick on vlan02 inet6 from fe80::/10 to ! <PrivateNetworks> flags S/SA keep state label "65d5bb0a-954a-495d-ae36-bb2423f804bf"
The Block LG_TVs rule sits at line 242/243 — well before the general Allow access only to Internet rule at line 385/386, for both IPv4 and IPv6. Since pf is quick and evaluates top-down, any traffic sourced from LG_TVs will now hit the block at line 242 and stop right there — it will never reach line 385.
jason@opnsense:~ $ sudo pfctl -t LG_TVs -T show
The LG_TVs table is completely empty in the live kernel, despite the rule referencing it being loaded correctly at line 242/243. This is exactly why traffic sails right past the block rule (an empty table matches nothing) and falls through to the general allow rule further down. This is the actual root cause. The fix,force a manual table load first, to test.
jason@opnsense:~ $ sudo pfctl -t LG_TVs -T add 192.168.107.6
1/1 addresses added.
jason@opnsense:~ $ sudo pfctl -t LG_TVs -T add 192.168.107.7
sudo pfctl -t LG_TVs -T show1/1 addresses added.
jason@opnsense:~ $ sudo pfctl -t LG_TVs -T show
192.168.107.6
192.168.107.7
This should now show both IPs. If it does, kill the states again and test the TVs immediately — if they get blocked now, we've fully confirmed the table-sync issue is the culprit (though this manual add won't survive a reboot/reload, so it's just for confirmation, not the permanent fix). The next command forces OPNsense to fully regenerate and reload the entire pf ruleset and all alias tables from the current config, which should definitely repopulate LG_TVs. Then check the table again.
jason@opnsense:~ $ sudo /usr/local/etc/rc.filter_configure
Configuring firewall.......done.
jason@opnsense:~ $ sudo pfctl -t LG_TVs -T show
192.168.107.6
192.168.107.7
jason@opnsense:~ $
Both IPs are now in the table. This confirms the theory completely: the table syncing from the alias definition to the running pf table was broken, and manually adding them fixed the immediate symptom.
#7
26.7 Series / Re: Problems with floating rul...
Last post by ivoruetsche - July 27, 2026, 11:44:03 PMIt's related to alias
#8
German - Deutsch / Re: Vielleicht ein Problem mit...
Last post by meyergru - July 27, 2026, 11:21:21 PMEhe Du an der Firewall herumspielst, verkleinere doch die Framed-MTU auf dem NPS, so dass es erst gar nicht zur Fragmentierung kommt - egal, woran es liegt, dass überhaupt eine auftritt (z.B. VPN o.ä.).
#9
26.7 Series / Re: Services widget
Last post by opnsenseuser - July 27, 2026, 11:01:53 PMSorry guys, i was on holiday :-)
Cicada and Vicuna Service widget color fix
https://github.com/opnsense/plugins/pull/5584
Cicada and Vicuna Service widget color fix
https://github.com/opnsense/plugins/pull/5584
#10
German - Deutsch / Re: Vielleicht ein Problem mit...
Last post by Patrick M. Hausen - July 27, 2026, 10:33:08 PMWarum sollte sie den fragmentieren? Sind nicht alle beteiligten Netze Ethernet mit einer MTU von 1500?
