"Recent posts
#41
General Discussion / Re: nfSensei ( fork pfsense )
Last post by Nullman - August 10, 2026, 02:18:59 PMQuote from: marvelolivia on August 10, 2026, 01:48:31 PMThe VPP support definitely sounds interesting, especially for a Linux-based firewall. I'm curious to see how this project develops.VyOS has VPP support.
Quote from: marvelolivia on August 10, 2026, 01:48:31 PMHas the source code/repository been made public yet?Not yet.
#42
General Discussion / Re: nfSensei ( fork pfsense )
Last post by marvelolivia - August 10, 2026, 01:48:31 PMThe VPP support definitely sounds interesting, especially for a Linux-based firewall. I'm curious to see how this project develops. Has the source code/repository been made public yet?
#43
26.1, 26,4 Series / Re: With IPv6, how to get both...
Last post by funtowne - August 10, 2026, 01:44:03 PMQuote from: mooh on August 10, 2026, 01:23:18 PMQuote from: funtowne on August 10, 2026, 06:38:51 AMOut of morbid curiosity I set up DNSMASQ with SLAAC as the mode with the IP range of my ULA ffd0::1000 to ffd0::2000 (ULA truncated).I'm fairly certain that it won't make a difference but a ULA is currently defined in the range of fd00::/8
That was a typo on my part, thanks for the nudge. The ULAs I have defined are indeed correct and sane. I'll leave the original post as is regardless.
#44
26.1, 26,4 Series / Re: With IPv6, how to get both...
Last post by mooh - August 10, 2026, 01:23:18 PMQuote from: funtowne on August 10, 2026, 06:38:51 AMOut of morbid curiosity I set up DNSMASQ with SLAAC as the mode with the IP range of my ULA ffd0::1000 to ffd0::2000 (ULA truncated).I'm fairly certain that it won't make a difference but a ULA is currently defined in the range of fd00::/8
#45
High availability / HA Upgrade from 26.1.11_10 to ...
Last post by relvy - August 10, 2026, 10:52:38 AMHello,
I want to upgrade my HA cluster from 26.1.11_10 to 26.7.1.
From the docs the basic steps are clear and I run the upgrades within 26.1.x this way.
But from reading the 26.7.1 release notes there are some special things not covered there:
- Migration of Outbound NAT -> Source NAT
- CPU Microcode
- PFSync compatibility due kernel upgrade
I successfully migrated from outbound NAT to Source NAT on both primary and secondary, so I expect no issue during upgrade.
IIUC my next step is to deinstall the microcode plugin on both machines and install it after the upgrade again due to bootloader changes ?
All other steps should be as the documentation says.
For a short window I will have my primary on FreeBSD 14.3 and my secondary on FreeBSD 15.1, where I must do the failover.
Is PFSync compatible or is there something I need to pay attention to ?
I want to upgrade my HA cluster from 26.1.11_10 to 26.7.1.
From the docs the basic steps are clear and I run the upgrades within 26.1.x this way.
Update your secondary unit and wait until it is online again
On your primary unit go to Interfaces ‣ Virtual IPs ‣ Status and click Enter Persistent CARP Maintenance Mode
You secondary unit is now MASTER, check if all services like DHCP, VPN, NAT are working correctly
If you ensured the update was fine, update your primary unit and hit Leave Persistent CARP Maintenance Mode
But from reading the 26.7.1 release notes there are some special things not covered there:
- Migration of Outbound NAT -> Source NAT
- CPU Microcode
- PFSync compatibility due kernel upgrade
I successfully migrated from outbound NAT to Source NAT on both primary and secondary, so I expect no issue during upgrade.
IIUC my next step is to deinstall the microcode plugin on both machines and install it after the upgrade again due to bootloader changes ?
All other steps should be as the documentation says.
For a short window I will have my primary on FreeBSD 14.3 and my secondary on FreeBSD 15.1, where I must do the failover.
Is PFSync compatible or is there something I need to pay attention to ?
#46
Web Proxy Filtering and Caching / Re: GUI : Transparent proxies ...
Last post by northbyte - August 10, 2026, 10:20:56 AMIt sounds like the main issue is that the transparent HTTP/HTTPS proxy rules are now intercepting traffic destined for the captive portal's own management interface. Since the Web GUI and guest network are both on the LAN interface, adding transparent proxying there can prevent access to 10.100.70.254.
I would first try to restore GUI access by connecting from the LAN and temporarily disabling the transparent proxy rules from the server's local console or configuration files. Once access is restored, make sure the management IP (10.100.70.254) and any required captive-portal authentication traffic are excluded from the interception rules.
For the HTTPS certificate problem, I would avoid using transparent HTTPS interception simply to solve certificate warnings. Modern browsers validate certificates strictly, and a captive portal should normally use a properly configured certificate and an appropriate authentication/redirect workflow. Testing the portal from a clean client while checking DNS, routing, firewall rules, and certificate-chain errors can help identify where the failure occurs.
If you're building this as a security-training environment, it can also be useful to perform a separate Wi-Fi/network security assessment after the portal is working. Paranoid Security provides information about Wi-Fi security audits and network testing here: Paranoid Security
I would first try to restore GUI access by connecting from the LAN and temporarily disabling the transparent proxy rules from the server's local console or configuration files. Once access is restored, make sure the management IP (10.100.70.254) and any required captive-portal authentication traffic are excluded from the interception rules.
For the HTTPS certificate problem, I would avoid using transparent HTTPS interception simply to solve certificate warnings. Modern browsers validate certificates strictly, and a captive portal should normally use a properly configured certificate and an appropriate authentication/redirect workflow. Testing the portal from a clean client while checking DNS, routing, firewall rules, and certificate-chain errors can help identify where the failure occurs.
If you're building this as a security-training environment, it can also be useful to perform a separate Wi-Fi/network security assessment after the portal is working. Paranoid Security provides information about Wi-Fi security audits and network testing here: Paranoid Security
#47
26.1, 26,4 Series / Re: With IPv6, how to get both...
Last post by funtowne - August 10, 2026, 09:14:37 AMQuote from: meyergru on August 10, 2026, 09:02:53 AMWhile you can syntactically do that and maybe the different RAs even get send out, I would not have expected it to work, because RAs are broadcasts, so they reach all clients. The mode flag determines if the clients should ask for DHCP offers. So, the clients will probably not request DHCP addresses once they see an RA that explicitely forbids them to.
I doubt that they would do that depending on specific ranges.
Reaching all clients is fine and likely with OP is after (me too!). The use case here is to have clients assign a ULA via both DHCPv6 & SLAAC, with SLAAC alone for GUA. I can see the use case here given that ISPs do not keep GUAs and therefore internal addressing stable. Other issues of course persist with client preference.
I managed to have this same setup working with kea a while back and may resume it with one of the 3rd-party (non repo) ddns plugins that work with unbound to register leases. Keeping BIND happy was just too much effort. Here's the little plugin: https://github.com/JameZUK/os-kea-unbound/
#48
26.1, 26,4 Series / Re: With IPv6, how to get both...
Last post by meyergru - August 10, 2026, 09:02:53 AMWhile you can syntactically do that and maybe the different RAs even get send out, I would not have expected it to work, because RAs are broadcasts, so they reach all clients. The mode flag determines if the clients should ask for DHCP offers. So, the clients will probably not request DHCP addresses once they see an RA that explicitely forbids them to.
I doubt that they would do that depending on specific ranges.
I doubt that they would do that depending on specific ranges.
#49
26.1, 26,4 Series / Re: With IPv6, how to get both...
Last post by funtowne - August 10, 2026, 06:38:51 AMQuote from: Monviech (Cedrik) on July 30, 2026, 11:52:54 AMMaybe dnsmasq can do it. You can configure different RA pools on the same interface with different flags from what I can see.
But I never tested that.
Out of morbid curiosity I set up DNSMASQ with SLAAC as the mode with the IP range of my ULA ffd0::1000 to ffd0::2000 (ULA truncated). I also set up ra-stateless for ::
Clients only seemed to get the slaac-generated IPs; the dhcpv6 ULA range did not assign a DHCP ULA address in the range above.
Happy to be wrong here in case I did a misconfigure, but manually-entered ranges including a prefix appear to be ignored for the use case of only defining a ULA range for dhcp. ::1000 to ::2000 without the prefix worked as expected, but only for the GUAs.
I'll double check my work and maybe open a bug report if needed, as the info tip for defining IP ranges does show a prefix (if defined on an interface of course) as a valid input for an ip range.
#50
General Discussion / Re: Roku DNS storm is impactin...
Last post by OPNenthu - August 10, 2026, 04:32:36 AMBack with an update.
While using the actual devices for a bit, we could maybe tell there was a little bit of random delay in app and video stream startup but it was quite acceptable. We could have just as well imagined it due to expectation bias.
The Unbound reports are overgrown now and taking long to load due to the tens of millions of accumulated queries, but this includes metrics from before the limiter was added. I also noticed the 'syslog-ng' service had stopped and needed a restart, which is concerning.
So... partially solved. I'll manually clear the reporting data if it doesn't rotate out soon and hopefully that will remain at manageable levels going forward. We'll see.
Appreciate all the tips so far.
---
@yourfriendarmando: thanks for that. Did you suggest it because there's a link between these two companies? I wouldn't be surprised but I don't know.
@newsense: that clears it up, thank you. As for your observation about the constant telemetry, I did notice something interesting when I was going through the Roku privacy settings that I don't recall seeing earlier (must have been added in an update?).
There were two entries in privacy settings: "Automatic Content Recognition (ACR)" and "Content Viewing Disclosure," both which can be unchecked but were enabled. This allows visual screen scraping and sending off information to 3rd parties and advertisers. Unfortunately, disabling them did not stop the DNS storm.
While using the actual devices for a bit, we could maybe tell there was a little bit of random delay in app and video stream startup but it was quite acceptable. We could have just as well imagined it due to expectation bias.
The Unbound reports are overgrown now and taking long to load due to the tens of millions of accumulated queries, but this includes metrics from before the limiter was added. I also noticed the 'syslog-ng' service had stopped and needed a restart, which is concerning.
So... partially solved. I'll manually clear the reporting data if it doesn't rotate out soon and hopefully that will remain at manageable levels going forward. We'll see.
Appreciate all the tips so far.
---
@yourfriendarmando: thanks for that. Did you suggest it because there's a link between these two companies? I wouldn't be surprised but I don't know.
@newsense: that clears it up, thank you. As for your observation about the constant telemetry, I did notice something interesting when I was going through the Roku privacy settings that I don't recall seeing earlier (must have been added in an update?).
There were two entries in privacy settings: "Automatic Content Recognition (ACR)" and "Content Viewing Disclosure," both which can be unchecked but were enabled. This allows visual screen scraping and sending off information to 3rd parties and advertisers. Unfortunately, disabling them did not stop the DNS storm.
