Recent posts

#1

Hardware and Performance / Re: AX88179B USB NIC: 57 -> 97...

Last post by web - Today at 02:33:48 PM

sorry, i've reported it to bugzilla, just wanted to put it here in case it helped someone. apologies for the short story, not very good at doing stuff like this.

#2

General Discussion / Re: nfSensei ( fork pfsense )

Last post by Nullman - Today at 02:18:59 PM

The VPP support definitely sounds interesting, especially for a Linux-based firewall. I'm curious to see how this project develops.

VyOS has VPP support.

Has the source code/repository been made public yet?

Not yet.

#3

General Discussion / Re: nfSensei ( fork pfsense )

Last post by marvelolivia - Today at 01:48:31 PM

The 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?

#4

26.1, 26,4 Series / Re: With IPv6, how to get both...

Last post by funtowne - Today at 01:44:03 PM

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'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.

#5

26.1, 26,4 Series / Re: With IPv6, how to get both...

Last post by mooh - Today at 01:23:18 PM

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'm fairly certain that it won't make a difference but a ULA is currently defined in the range of fd00::/8

#6

High availability / HA Upgrade from 26.1.11_10 to ...

Last post by relvy - Today at 10:52:38 AM

Hello,

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 ?

#7

Web Proxy Filtering and Caching / Re: GUI : Transparent proxies ...

Last post by northbyte - Today at 10:20:56 AM

It 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

#8

26.1, 26,4 Series / Re: With IPv6, how to get both...

Last post by funtowne - Today at 09:14:37 AM

While 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/

#9

26.1, 26,4 Series / Re: With IPv6, how to get both...

Last post by meyergru - Today at 09:02:53 AM

While 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.

#10

26.1, 26,4 Series / Re: With IPv6, how to get both...

Last post by funtowne - Today at 06:38:51 AM

Maybe 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.