"Recent posts
#21
26.1, 26,4 Series / Re: Odd Kea DHCPv6 behavior...
Last post by Monviech (Cedrik) - May 15, 2026, 08:04:57 PMThe GUI does not use the lease files anymore to display leases, it interacts directly with the unix socket now.
You need the leases hook library in your config file.
https://github.com/opnsense/core/blob/49b54ef032124e36eed2ad6fb19a9cc518f576a1/src/opnsense/mvc/app/models/OPNsense/Kea/KeaDhcpv6.php#L387
Afterward try executing the leases script to see if it returns anything:
https://github.com/opnsense/core/blob/master/src/opnsense/scripts/kea/get_kea_leases.py
You need the leases hook library in your config file.
https://github.com/opnsense/core/blob/49b54ef032124e36eed2ad6fb19a9cc518f576a1/src/opnsense/mvc/app/models/OPNsense/Kea/KeaDhcpv6.php#L387
Afterward try executing the leases script to see if it returns anything:
https://github.com/opnsense/core/blob/master/src/opnsense/scripts/kea/get_kea_leases.py
#22
26.1, 26,4 Series / Re: Unbound not able to retrie...
Last post by Taomyn - May 15, 2026, 07:47:40 PMI found the problem - ::/0 was somehow added at the end of the "Rebind protection networks" option of Unbound/Advanced which can apparently happen randomly when changing other configuration settings of Unbound. After removing it Unbound started returning AAAA lookups correctly again.
#23
Zenarmor (Sensei) / Re: Zenarmor performance expec...
Last post by jaykumar2005 - May 15, 2026, 07:45:20 PMUpdated the Tunables, rebooted the firewall, but I am afraid it did not make much of a difference
Tunable: dev.netmap.generic_rings, Value: 6
Tunable: dev.netmap.generic_rings, Value: 6
#24
26.1, 26,4 Series / Odd Kea DHCPv6 behavior...
Last post by Ed V. - May 15, 2026, 07:26:09 PMSo this one is weird.
If you recall, I'm the oddball that uses manual configs for my DHCP setup (the whole Cable Modem shared network /IP thing).
With the latest update to v26.1.8_5, the DHCP6 server has started exhibiting strange behavior.
Setting the stage...
The OpnSense Kea platform is the only DHCPv6 in my environment.
It appears to be the latest version from OpnSense:
With the "Shared Networks" config in `kea-dhcp6.conf`, I can run the extended tests and they come back clean:
The server starts and tracks handing out addresses from the 2001:579:4c:2700:: range, but does not log anything in the fde4:b3e2:db9e:1000:: range.
Despite that, clients receive both 2001:579:4c:2700:: and fde4:b3e2:db9e:1000 addresses from OpnSense/Kea.
On top of it all, even though there are leases recorded in the `/var/log/db/kea/kea-leases6.csv` and `/var/log/db/kea/kea-leases.csv.2` files, the WebUI reports no results found (screen capture attached).
My config files for Kea DHCP haven't changed since v25.* (and were working as expected in that release series), so I'm not sure what's going on here...
Any thoughts? Clues? Other things for me to dig out and post for review?
If you recall, I'm the oddball that uses manual configs for my DHCP setup (the whole Cable Modem shared network /IP thing).
With the latest update to v26.1.8_5, the DHCP6 server has started exhibiting strange behavior.
Setting the stage...
The OpnSense Kea platform is the only DHCPv6 in my environment.
It appears to be the latest version from OpnSense:
Code Select
# kea-dhcp6 -v
3.0.3With the "Shared Networks" config in `kea-dhcp6.conf`, I can run the extended tests and they come back clean:
Code Select
# kea-dhcp6 -T /usr/local/etc/kea/kea-dhcp6.conf
2026-05-15 12:10:01.791 WARN [kea-dhcp6.dhcpsrv/71095.0x4b07eb05c008] DHCPSRV_MT_DISABLED_QUEUE_CONTROL disabling dhcp queue control when multi-threading is enabled.
2026-05-15 12:10:01.791 WARN [kea-dhcp6.dhcp6/71095.0x4b07eb05c008] DHCP6_RESERVATIONS_LOOKUP_FIRST_ENABLED Multi-threading is enabled and host reservations lookup is always performed first.
2026-05-15 12:10:01.792 INFO [kea-dhcp6.hooks/71095.0x4b07eb05c008] HOOKS_LIBRARY_CLOSED hooks library /usr/local/lib/kea/hooks/libdhcp_lease_cmds.so successfully closed
2026-05-15 12:10:01.793 INFO [kea-dhcp6.hooks/71095.0x4b07eb05c008] HOOKS_LIBRARY_CLOSED hooks library /usr/local/lib/kea/hooks/libdhcp_host_cmds.so successfully closed
2026-05-15 12:10:01.793 INFO [kea-dhcp6.dhcpsrv/71095.0x4b07eb05c008] DHCPSRV_CFGMGR_NEW_SUBNET6 a new subnet has been added to configuration: 2001:579:4c:2700::/64 with params: t1=21600, t2=37800, preferred-lifetime=27000, valid-lifetime=43200, rapid-commit is false
2026-05-15 12:10:01.793 INFO [kea-dhcp6.dhcpsrv/71095.0x4b07eb05c008] DHCPSRV_CFGMGR_NEW_SUBNET6 a new subnet has been added to configuration: fde4:b3e2:db9e:1000::/64 with params: t1=21600, t2=37800, preferred-lifetime=27000, valid-lifetime=43200, rapid-commit is false
2026-05-15 12:10:01.794 INFO [kea-dhcp6.dhcpsrv/71095.0x4b07eb05c008] DHCPSRV_CFGMGR_NEW_SUBNET6 a new subnet has been added to configuration: 2001:579:4c:2701::/64 with params: t1=21600, t2=37800, preferred-lifetime=27000, valid-lifetime=43200
2026-05-15 12:10:01.794 INFO [kea-dhcp6.dhcpsrv/71095.0x4b07eb05c008] DHCPSRV_CFGMGR_NEW_SUBNET6 a new subnet has been added to configuration: fde4:b3e2:db9e:2000::/64 with params: t1=21600, t2=37800, preferred-lifetime=27000, valid-lifetime=43200
2026-05-15 12:10:01.794 INFO [kea-dhcp6.dhcpsrv/71095.0x4b07eb05c008] DHCPSRV_CFGMGR_SOCKET_TYPE_SELECT using socket type raw
2026-05-15 12:10:01.794 INFO [kea-dhcp6.dhcpsrv/71095.0x4b07eb05c008] DHCPSRV_CFGMGR_ADD_IFACE listening on interface ixl0
2026-05-15 12:10:01.794 INFO [kea-dhcp6.dhcpsrv/71095.0x4b07eb05c008] DHCPSRV_CFGMGR_ADD_IFACE listening on interface vlan01
2026-05-15 12:10:01.796 INFO [kea-dhcp6.lease-cmds-hooks/71095.0x4b07eb05c008] LEASE_CMDS_INIT_OK loading Lease Commands hooks library successful
2026-05-15 12:10:01.796 INFO [kea-dhcp6.hooks/71095.0x4b07eb05c008] HOOKS_LIBRARY_LOADED hooks library /usr/local/lib/kea/hooks/libdhcp_lease_cmds.so successfully loaded
2026-05-15 12:10:01.797 INFO [kea-dhcp6.host-cmds-hooks/71095.0x4b07eb05c008] HOST_CMDS_INIT_OK loading Host Commands hooks library successful
2026-05-15 12:10:01.797 INFO [kea-dhcp6.hooks/71095.0x4b07eb05c008] HOOKS_LIBRARY_LOADED hooks library /usr/local/lib/kea/hooks/libdhcp_host_cmds.so successfully loaded
2026-05-15 12:10:01.797 INFO [kea-dhcp6.dhcpsrv/71095.0x4b07eb05c008] DHCPSRV_MEMFILE_DB opening memory file lease database: persist=true type=memfile universe=6
2026-05-15 12:10:01.797 INFO [kea-dhcp6.dhcpsrv/71095.0x4b07eb05c008] DHCPSRV_MEMFILE_LEASE_FILE_LOAD loading leases from file /var/db/kea/kea-leases6.csv.2
2026-05-15 12:10:01.798 INFO [kea-dhcp6.dhcpsrv/71095.0x4b07eb05c008] DHCPSRV_MEMFILE_LEASE_FILE_LOAD loading leases from file /var/db/kea/kea-leases6.csv
2026-05-15 12:10:01.798 INFO [kea-dhcp6.dhcpsrv/71095.0x4b07eb05c008] DHCPSRV_MEMFILE_BUILD_EXTENDED_INFO_TABLES6 building extended info tables saw 17 leases, extended info sanity checks modified 0 leases and 0 leases were entered into tables
2026-05-15 12:10:01.798 INFO [kea-dhcp6.dhcpsrv/71095.0x4b07eb05c008] DHCPSRV_MEMFILE_LFC_SETUP setting up the Lease File Cleanup interval to 3600 sec
2026-05-15 12:10:01.798 INFO [kea-dhcp6.dhcpsrv/71095.0x4b07eb05c008] DHCPSRV_LEASE_MGR_BACKENDS_REGISTERED the following lease backend types are available: memfile
2026-05-15 12:10:01.798 INFO [kea-dhcp6.hosts/71095.0x4b07eb05c008] HOSTS_BACKENDS_REGISTERED the following host backend types are available:
2026-05-15 12:10:01.798 INFO [kea-dhcp6.dhcpsrv/71095.0x4b07eb05c008] DHCPSRV_FORENSIC_BACKENDS_REGISTERED the following forensic backend types are available:
2026-05-15 12:10:01.798 INFO [kea-dhcp6.database/71095.0x4b07eb05c008] CONFIG_BACKENDS_REGISTERED the following config backend types are available:
2026-05-15 12:10:01.798 INFO [kea-dhcp6.host-cmds-hooks/71095.0x4b07eb05c008] HOST_CMDS_DEINIT_OK unloading Host Commands hooks library successful
2026-05-15 12:10:01.798 INFO [kea-dhcp6.lease-cmds-hooks/71095.0x4b07eb05c008] LEASE_CMDS_DEINIT_OK unloading Lease Commands hooks library successful
2026-05-15 12:10:01.798 INFO [kea-dhcp6.hooks/71095.0x4b07eb05c008] HOOKS_LIBRARY_CLOSED hooks library /usr/local/lib/kea/hooks/libdhcp_host_cmds.so successfully closed
2026-05-15 12:10:01.798 INFO [kea-dhcp6.hooks/71095.0x4b07eb05c008] HOOKS_LIBRARY_CLOSED hooks library /usr/local/lib/kea/hooks/libdhcp_lease_cmds.so successfully closedThe server starts and tracks handing out addresses from the 2001:579:4c:2700:: range, but does not log anything in the fde4:b3e2:db9e:1000:: range.
Code Select
2026-05-15T09:26:13-05:00Informationalkea-dhcp6INFO [kea-dhcp6.dhcpsrv.0x515279a5c008] DHCPSRV_MEMFILE_LFC_START starting Lease File Cleanup
2026-05-15T09:26:11-05:00Informationalkea-dhcp4INFO [kea-dhcp4.dhcpsrv.0x516d8645c008] DHCPSRV_MEMFILE_LFC_EXECUTE executing Lease File Cleanup using: /usr/local/sbin/kea-lfc -4 -x /var/db/kea/kea-leases4.csv.2 -i /var/db/kea/kea-leases4.csv.1 -o /var/db/kea/kea-leases4.csv.output -f /var/db/kea/kea-leases4.csv.completed -p /var/db/kea/kea-leases4.csv.pid -c ignored-path
2026-05-15T09:26:11-05:00Informationalkea-dhcp4INFO [kea-dhcp4.dhcpsrv.0x516d8645c008] DHCPSRV_MEMFILE_LFC_START starting Lease File Cleanup
2026-05-15T09:20:51-05:00Informationalkea-dhcp6INFO [kea-dhcp6.commands.0x515279a5c008] COMMAND_RECEIVED Received command 'lease6-get-all'
2026-05-15T09:20:51-05:00Informationalkea-dhcp6INFO [kea-dhcp6.commands.0x515279a5c008] COMMAND_RECEIVED Received command 'config-get'
2026-05-15T09:20:49-05:00Informationalkea-dhcp4INFO [kea-dhcp4.commands.0x516d8645c008] COMMAND_RECEIVED Received command 'lease4-get-all'
2026-05-15T09:20:49-05:00Informationalkea-dhcp4INFO [kea-dhcp4.commands.0x516d8645c008] COMMAND_RECEIVED Received command 'config-get'
2026-05-15T09:16:53-05:00Informationalkea-dhcp6INFO [kea-dhcp6.dhcp6.0x515279a76008] DHCP6_QUERY_LABEL received query: duid=[00:03:00:01:84:69:93:8f:d0:ca], [no hwaddr info], tid=0x6e1e19
2026-05-15T09:13:19-05:00Informationalkea-dhcp6INFO [kea-dhcp6.packets.0x515279a76008] DHCP6_PACKET_SEND duid=[00:01:00:01:2d:a9:af:f9:6c:7e:67:bb:73:f0], [no hwaddr info], tid=0x4031d4: trying to send packet REPLY (type 7) from [ff02::1:2]:547 to [fe80::469:89b5:704e:d6e9]:546 on interface ixl0
2026-05-15T09:13:19-05:00Informationalkea-dhcp6INFO [kea-dhcp6.leases.0x515279a76008] DHCP6_LEASE_ALLOC duid=[00:01:00:01:2d:a9:af:f9:6c:7e:67:bb:73:f0], [no hwaddr info], tid=0x4031d4: lease for address 2001:579:4c:2700::3 and iaid=0 has been allocated for 43200 seconds
2026-05-15T09:13:19-05:00Informationalkea-dhcp6INFO [kea-dhcp6.packets.0x515279a76008] DHCP6_PACKET_RECEIVED duid=[00:01:00:01:2d:a9:af:f9:6c:7e:67:bb:73:f0], [no hwaddr info], tid=0x4031d4: REQUEST (type 3) received from fe80::469:89b5:704e:d6e9 to ff02::1:2 on interface ixl0
2026-05-15T09:13:19-05:00Informationalkea-dhcp6INFO [kea-dhcp6.dhcp6.0x515279a76008] DHCP6_QUERY_LABEL received query: duid=[00:01:00:01:2d:a9:af:f9:6c:7e:67:bb:73:f0], [no hwaddr info], tid=0x4031d4
2026-05-15T09:13:18-05:00Informationalkea-dhcp6INFO [kea-dhcp6.packets.0x515279a76008] DHCP6_PACKET_SEND duid=[00:01:00:01:2d:a9:af:f9:6c:7e:67:bb:73:f0], [no hwaddr info], tid=0x4acd6: trying to send packet ADVERTISE (type 2) from [ff02::1:2]:547 to [fe80::469:89b5:704e:d6e9]:546 on interface ixl0
2026-05-15T09:13:18-05:00Informationalkea-dhcp6INFO [kea-dhcp6.leases.0x515279a76008] DHCP6_LEASE_ADVERT duid=[00:01:00:01:2d:a9:af:f9:6c:7e:67:bb:73:f0], [no hwaddr info], tid=0x4acd6: lease for address 2001:579:4c:2700::3 and iaid=0 will be advertised
2026-05-15T09:13:18-05:00Informationalkea-dhcp6INFO [kea-dhcp6.packets.0x515279a76008] DHCP6_PACKET_RECEIVED duid=[00:01:00:01:2d:a9:af:f9:6c:7e:67:bb:73:f0], [no hwaddr info], tid=0x4acd6: SOLICIT (type 1) received from fe80::469:89b5:704e:d6e9 to ff02::1:2 on interface ixl0
2026-05-15T09:13:18-05:00Informationalkea-dhcp6INFO [kea-dhcp6.dhcp6.0x515279a76008] DHCP6_QUERY_LABEL received query: duid=[00:01:00:01:2d:a9:af:f9:6c:7e:67:bb:73:f0], [no hwaddr info], tid=0x4acd6Despite that, clients receive both 2001:579:4c:2700:: and fde4:b3e2:db9e:1000 addresses from OpnSense/Kea.
Code Select
DHCP Enabled. . . . . . . . . . . : Yes
Autoconfiguration Enabled . . . . : Yes
IPv6 Address. . . . . . . . . . . : 2001:579:4c:2700::4(Preferred)
Lease Obtained. . . . . . . . . . : Thursday, May 14, 2026 23:40:48
Lease Expires . . . . . . . . . . : Friday, May 15, 2026 22:55:48
IPv6 Address. . . . . . . . . . . : 2001:579:4c:2700:67e0:5d83:785d:2d2c(Preferred)
IPv6 Address. . . . . . . . . . . : fde4:b3e2:db9e:1000:2941:55e:e973:29ad(Preferred)
Temporary IPv6 Address. . . . . . : 2001:579:4c:2700:e992:445d:788e:8d84(Preferred)
Temporary IPv6 Address. . . . . . : fde4:b3e2:db9e:1000:8141:11bc:3518:2088(Deprecated)
Link-local IPv6 Address . . . . . : fe80::1f87:9cc:d92e:b807%11(Preferred)
IPv4 Address. . . . . . . . . . . : 192.168.144.21(Preferred)
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Lease Obtained. . . . . . . . . . : Tuesday, May 12, 2026 23:33:42
Lease Expires . . . . . . . . . . : Saturday, May 16, 2026 04:22:55On top of it all, even though there are leases recorded in the `/var/log/db/kea/kea-leases6.csv` and `/var/log/db/kea/kea-leases.csv.2` files, the WebUI reports no results found (screen capture attached).
Code Select
# cat /var/db/kea/kea-leases6.csv.2
address,duid,valid_lifetime,expire,subnet_id,pref_lifetime,lease_type,iaid,prefix_len,fqdn_fwd,fqdn_rev,hostname,hwaddr,state,user_context,hwtype,hwaddr_source,pool_id
2001:579:4c:2700::1,00:03:00:01:ac:5a:f0:32:d4:46,43200,1778886008,1,27000,0,4029862982,128,1,1,dynamic-2001-579-4c-2700--1.lan.null-route.us.,ac:5a:f0:32:d4:46,0,,1,2,0
2001:579:4c:2700::2,00:01:00:01:2d:a9:af:f9:6c:7e:67:bb:73:f0,43200,1778895409,1,27000,0,1,128,1,1,dynamic-2001-579-4c-2700--2.lan.null-route.us.,6c:7e:67:bb:73:f0,0,,1,2,0
2001:579:4c:2700::3,00:01:00:01:2d:a9:af:f9:6c:7e:67:bb:73:f0,43200,1778897599,1,27000,0,0,128,1,1,dynamic-2001-579-4c-2700--3.lan.null-route.us.,6c:7e:67:bb:73:f0,0,,1,2,0
2001:579:4c:2700::4,00:01:01:00:2f:06:d4:e6:9c:6b:00:aa:e2:94,43200,1778890248,1,27000,0,127691520,128,0,1,dynamic-2001-579-4c-2700--4.lan.null-route.us.,9c:6b:00:aa:e2:94,0,,256,2,0
2001:579:4c:2700::5,00:04:e1:18:49:99:32:fc:ad:1a:6e:cd:4b:f4:8c:94:e4:d2,43200,1778884562,1,27000,0,3055685611,128,1,1,dynamic-2001-579-4c-2700--5.lan.null-route.us.,,0,,,,0
2001:579:4c:2700::6,00:04:14:01:94:3d:5e:e1:43:c6:ef:f0:2f:6e:d3:15:9b:36,43200,1778889956,1,27000,0,726689589,128,1,1,dynamic-2001-579-4c-2700--6.lan.null-route.us.,,0,,,,0
2001:579:4c:2700::7,00:04:7d:69:f4:9b:51:6d:d2:61:44:7e:be:66:23:bb:f8:af,43200,1778890603,1,27000,0,4174257057,128,1,1,dynamic-2001-579-4c-2700--7.lan.null-route.us.,,0,,,,0
2001:579:4c:2700::8,00:04:47:f8:73:e6:1d:05:55:e8:aa:1b:a0:8a:7c:50:84:9b,43200,1778890230,1,27000,0,726689589,128,1,1,dynamic-2001-579-4c-2700--8.lan.null-route.us.,,0,,,,0
2001:579:4c:2700:aab:4e87:b033:ca45,00:03:00:01:bc:32:b2:a9:57:35,86392,1778896156,1,14392,0,0,128,1,1,,bc:32:b2:a9:57:35,4,,1,2,0
2001:579:4c:2700:1f60:865e:90da:b0cd,00:03:00:01:58:79:e0:21:af:00,86393,1778895689,1,14393,0,0,128,1,1,,58:79:e0:21:af:00,4,,1,2,0
2001:579:4c:2700:2177:9653:8512:3125,00:03:00:01:bc:32:b2:a9:57:35,86392,1778932177,1,14392,0,0,128,1,1,,bc:32:b2:a9:57:35,4,,1,2,0
2001:579:4c:2700:2659:ac73:43d1:1a7f,00:03:00:01:58:79:e0:21:af:00,86392,1778895688,1,14392,0,0,128,1,1,,58:79:e0:21:af:00,4,,1,2,0
2001:579:4c:2700:5df4:3144:fa64:a004,00:03:00:01:ac:c0:48:f0:79:89,86393,1778929395,1,14393,0,0,128,1,1,,ac:c0:48:f0:79:89,4,,1,2,0
2001:579:4c:2700:9efa:b659:3293:8bf2,00:03:00:01:bc:32:b2:a9:57:35,86393,1778896089,1,14393,0,0,128,1,1,,bc:32:b2:a9:57:35,4,,1,2,0
2001:579:4c:2700:c864:942c:b236:4510,00:03:00:01:ac:c0:48:f0:79:89,86393,1778929395,1,14393,0,0,128,1,1,,ac:c0:48:f0:79:89,4,,1,2,0
2001:579:4c:2700:cc20:ce97:a15c:252c,00:03:00:01:bc:32:b2:a9:57:35,86392,1778932178,1,14392,0,0,128,1,1,,bc:32:b2:a9:57:35,4,,1,2,0My config files for Kea DHCP haven't changed since v25.* (and were working as expected in that release series), so I'm not sure what's going on here...
Any thoughts? Clues? Other things for me to dig out and post for review?
#25
General Discussion / Stumped - Tracking down incomi...
Last post by lmoore - May 15, 2026, 07:25:49 PMI'm trying to work out how to determine what traffic is being evaluated on WAN rule.
My understanding of rules being evaluated in pf are as per the first paragraph of https://docs.opnsense.org/manual/firewall.html#states
If all connections originating from the Internet are blocked before they reach the OPNsense WAN interface, it would seem reasonable to expect that any WAN rules for incoming packets in OPNsense should not be evaluating any packets.
I did some reading about pf and noted that if scrub is used it can affect the rule evaluation. I disabled scrub in OPNsense and disabled any active Normalization rules.
In addition, I enabled logging of all packets except for Outbound NAT.
To prevent any connections originating from the Internet I set up a transparent firewall between the WAN port and the DSL modem.
On the transparent firewall, my initial rules were set to pass all in on em1 and em0. After verifying all was working, I then changed the rule on em0 to block in all. After the rule was updated there were some stateful connections. After the last stateful entry expired, all incoming packets from the Internet were blocked, thus no more packets were reaching the WAN port of OPNsense.
After the last incoming connection was seen, the rules in OPNsense were re-applied to reset the counters.
FreeBSD's version of pf includes the ability to filter Ethernet frames.
With this knowledge I ran tcpdump in promiscuous mode on OPNsense's WAN interface using the expression 'not ip'. This only revealed ARP packets between OPNsense and my ISP's equipment, and at rate of 6 per hour. Not enough to match the number of evaluations on the WAN rule in question.
This set up has been running for over 25 hours now.
Is anyone able to provide some insight why the Floating Rule with description Inbound Q-Feeds Block List is evaluating packets?
Also, there are no further evaluations in the floating rules after it, with the last inbound rule being Nothing Else Blocked Inbound from Internet.
My understanding of rules being evaluated in pf are as per the first paragraph of https://docs.opnsense.org/manual/firewall.html#states
If all connections originating from the Internet are blocked before they reach the OPNsense WAN interface, it would seem reasonable to expect that any WAN rules for incoming packets in OPNsense should not be evaluating any packets.
I did some reading about pf and noted that if scrub is used it can affect the rule evaluation. I disabled scrub in OPNsense and disabled any active Normalization rules.
In addition, I enabled logging of all packets except for Outbound NAT.
To prevent any connections originating from the Internet I set up a transparent firewall between the WAN port and the DSL modem.
On the transparent firewall, my initial rules were set to pass all in on em1 and em0. After verifying all was working, I then changed the rule on em0 to block in all. After the rule was updated there were some stateful connections. After the last stateful entry expired, all incoming packets from the Internet were blocked, thus no more packets were reaching the WAN port of OPNsense.
After the last incoming connection was seen, the rules in OPNsense were re-applied to reset the counters.
FreeBSD's version of pf includes the ability to filter Ethernet frames.
With this knowledge I ran tcpdump in promiscuous mode on OPNsense's WAN interface using the expression 'not ip'. This only revealed ARP packets between OPNsense and my ISP's equipment, and at rate of 6 per hour. Not enough to match the number of evaluations on the WAN rule in question.
This set up has been running for over 25 hours now.
Is anyone able to provide some insight why the Floating Rule with description Inbound Q-Feeds Block List is evaluating packets?
Also, there are no further evaluations in the floating rules after it, with the last inbound rule being Nothing Else Blocked Inbound from Internet.
#26
26.1, 26,4 Series / Re: How to pin a Host to a Gat...
Last post by zartoz - May 15, 2026, 07:07:55 PMYeah, I cannot get it to apply to the traffic. Everything continues to apply the "Default allow LAN to any rule" to the traffic for the host that I specify in the Firewall Rule. I did move it to the top of the Rules list and set it to Quick but it still doesn't match any traffic from that host to the rule that I created.
I did try to create a Floating Rule as well but that also wouldn't apply to the traffic. I created a 2nd WAN Group with the LTE interface as Tier 1 and DSL as Tier 2 but that also wouldn't route over LTE.
If I change the Gateways Configuration to make the LTE Gateway as "Active" with Priority 1, it then will route all traffic over that interface.
Is it not possible to force route specific traffic over one interface with a Failover WAN Group configured?
I did try to create a Floating Rule as well but that also wouldn't apply to the traffic. I created a 2nd WAN Group with the LTE interface as Tier 1 and DSL as Tier 2 but that also wouldn't route over LTE.
If I change the Gateways Configuration to make the LTE Gateway as "Active" with Priority 1, it then will route all traffic over that interface.
Is it not possible to force route specific traffic over one interface with a Failover WAN Group configured?
#27
26.1, 26,4 Series / "Last updated" for URL table (...
Last post by OPNsense4ever - May 15, 2026, 06:56:01 PMHello,
I have a number or URL Table (IPs) aliases like Cloudflare and Google. When I view them I see the Last updated field is a long time ago even though the refresh intervals are 7 days at most. Is Last updated in this case the last time there was a change? Is there a column that would show last refreshed?
Thanks!
I have a number or URL Table (IPs) aliases like Cloudflare and Google. When I view them I see the Last updated field is a long time ago even though the refresh intervals are 7 days at most. Is Last updated in this case the last time there was a change? Is there a column that would show last refreshed?
Thanks!
#28
General Discussion / Re: NAT redirect - DNS timeout
Last post by jbernardo - May 15, 2026, 05:00:53 PMQuote from: nero355 on May 14, 2026, 01:45:21 PMI think you forgot to select IPv4 in the first screenshot ?
Redirects for IPv6 are a bit different than those for IPv4 according to the earlier mentioned topic!
Well caught, I think it got away with that because I have IPV6 disabled. Orange Belgium still has to provide it, they are still IPV4 only for residential customers, so I am stuck without it.
#29
German - Deutsch / Re: IPSEC - zwei SubNetze in P...
Last post by Patrick M. Hausen - May 15, 2026, 04:33:41 PMJe nach Gegenstelle musst du entweder
- 2 Subnetze in einen Phase 2 Eintrag schreiben oder
- 2 getrennte Phase 2 Einträge mit je einem Subnetz anlegen.
Wenn bei einer Variante immer nur ein Subnetz funktioniert, probier die andere.
- 2 Subnetze in einen Phase 2 Eintrag schreiben oder
- 2 getrennte Phase 2 Einträge mit je einem Subnetz anlegen.
Wenn bei einer Variante immer nur ein Subnetz funktioniert, probier die andere.
#30
German - Deutsch / IPSEC - zwei SubNetze in Phase...
Last post by holehner - May 15, 2026, 04:20:37 PMStand OPNSense 26.1.6_2
Hallo Zusammen,
ich habe mehrere IPSEC Verbindungen über Connections eingerichtet. In allen Tunnels sind zwei Subnetze als Quelle (192.168.22.0/24 und 192.168.33.0/24) enthalten.
Die meisten Tunnels funktionieren tadellos.
Dann habe ich aber zwei Tunnels bei denen immer ein Netz in Phase 2 im laufenden Betrieb wegfällt.
Wenn ich den Tunnel erneut starte, geht dieser sofort mit beiden Netzen aktiv!
Bei einem Tunnel weiß ich, dass auf der anderen Seite eine Cisco Meraki ist.
Die Einstellungen pro Child sind:
Mode-Tunnel
Start action: Start
DPD action: Clear
Ich habe auch schon Start/Start verwendet, jedoch hat das nix gebracht.
Habt Ihr Erfahrung mit so einer Konstellation?
Vielen Dank schon Mal, Gruß Heiko
Hallo Zusammen,
ich habe mehrere IPSEC Verbindungen über Connections eingerichtet. In allen Tunnels sind zwei Subnetze als Quelle (192.168.22.0/24 und 192.168.33.0/24) enthalten.
Die meisten Tunnels funktionieren tadellos.
Dann habe ich aber zwei Tunnels bei denen immer ein Netz in Phase 2 im laufenden Betrieb wegfällt.
Wenn ich den Tunnel erneut starte, geht dieser sofort mit beiden Netzen aktiv!
Bei einem Tunnel weiß ich, dass auf der anderen Seite eine Cisco Meraki ist.
Die Einstellungen pro Child sind:
Mode-Tunnel
Start action: Start
DPD action: Clear
Ich habe auch schon Start/Start verwendet, jedoch hat das nix gebracht.
Habt Ihr Erfahrung mit so einer Konstellation?
Vielen Dank schon Mal, Gruß Heiko
