According to my tests, the valid syntax $config['interfaces']['opt1']['enable'] = ""; or unset($config['interfaces']['opt1']['enable']); interface_reconfigure('opt1'); write_config('enable/disable opt1 interface'); exec Real-time enable/disable interface No need for system_reboot_sync();

pfSense-repoc-5b49b75f2a3cdf2349139152b2ca52e78dcbfd18_GL0.tar.gz doesn't seem to exist in /usr/local/poudriere/ports/Kontrol_v2_7_0/distfiles/. => Attempting to fetch https://gitlab.netgate.com/pfSense/repoc/-/archive/5b49b75f2a3cdf2349139152b2ca52e78dcbfd18.tar.gz?dummy=/pfSense-repoc-5b49b75f2a3cdf2349139152b2ca52e78dcbfd18_GL0.tar.gz fetch: https://gitlab.netgate.com/pfSense/repoc/-/archive/5b49b75f2a3cdf2349139152b2ca52e78dcbfd18.tar.gz?dummy=/pfSense-repoc-5b49b75f2a3cdf2349139152b2ca52e78dcbfd18_GL0.tar.gz: Host does not resolve => Attempting to fetch http://distcache.FreeBSD.org/ports-distfiles/pfSense-repoc-5b49b75f2a3cdf2349139152b2ca52e78dcbfd18_GL0.tar.gz fetch: http://distcache.FreeBSD.org/ports-distfiles/pfSense-repoc-5b49b75f2a3cdf2349139152b2ca52e78dcbfd18_GL0.tar.gz: Not Found => Couldn't fetch it - please try to retrieve this => port manually into /usr/local/poudriere/ports/Kontrol_v2_7_0/distfiles/ and try again. *** Error code 1 This is pointing to some internal netgate repository.

The 3100 is a 32-bit platform and those counters rolled over and went negative. https://redmine.pfsense.org/issues/14440

@Gertjan Pfsense has the ability in theory to be the first firewall to compartmentalize docker os signatures apart from the host machines and actually control traffic in that manner:) wouldn't that be cool? Again, invasive nation state actors only attack walls at their weakest areas.

Hello, I came across the same topic, it was very useful for me. This is how I decided to implement it in ansible. - name: "Generate a virtual ip address uniq id" ansible.builtin.debug: var: query('community.general.random_string', upper=false, special=false, min_numeric=10, min_lower=3, length=13) # Example result: ['202121w730p1q']

@jimp super helpful - just what I needed! I'm a powershell guy and here's where I landed on this in case anyone else is in the same boat: $hardwareModelRaw = & "$env:ProgramFiles\putty\plink.exe" admin@$pfSenseIP -pw $pfSensePW -batch -hostkey $pfSenseHostKey 'sysctl dev.netgate.desc' $pos = $hardwareModelRaw.indexof(": ") $hardwareModel = $hardwareModelRaw.substring($pos+2) $pfSerialNumber = & "$env:ProgramFiles\putty\plink.exe" admin@$pfSenseIP -pw $pfSensePW -batch -hostkey $pfSenseHostKey '/bin/kenv -q uboot.boardsn'

@cloudless-smart-home said in Ubiquiti intigration package?: I do the same. any advice on reining them in? things are working fine, I guess, but always trying to learn how to improve / secure my home lab setup. In paranoid setups, we've setup the management network for Unifi stuff separate from the default VLAN and actually use that (default VLAN) as a "sort of jail" where devices won't get an IP and are just isolated. So Mgmt runs with all other networks on different VLANs. Initially that's a bit harder to set up so you'll not loose connection between the controller and at least one switch but it works :) After that it's really your choice. If you trust the updates and stuff you could leave outgoing HTTP/S open so switches, APs etc. can get their firmware themselves. Others like it better if only the controller itself has web access, no one else. You'd need to deploy the firmware via the controller then by caching it first there and then rolling the upgrading the controller should send it to the device. Or go full defense and revoke internet access from management alltogether and only open it for patch days. That choice is yours :) Otherwise reigning them in also means checking for things like RSTP etc. going wild etc. ;) Cheers

@jonathanlee I don't see it, but, I suspect 23.05 is not available to test yet. It's not on other hardware, either.

@jimp Thank you! That worked!

@steveits Perfect. Thanks!

It's all typical subnet math, nothing special about it. The code for checking that is in util.inc, like check_subnets_overlap() but you might also look at things like gen_subnet() and get_subnet_mask() and the v4/v6 specific ones. The question is very vague, though. We need more context to know what you're attempting to do that the current checks aren't allowing to know if it's valid. While nothing stops something from using the network/broadcast addresses of a subnet (e.g. if it's routed to the firewall, all can be used for NAT so long as they aren't defined on an interface), you still can't force things to work that are not valid at a subnet level when used directly on an interface. When using larger subnets, there is indeed nothing special about those addresses either. Such as when using a /23, it's valid to have clients use the .254 and .0 addresses in the middle of the /23.

@heper nice!

or can I just rebuild a kernel outside and replace the kernel on a running pfSense ? I would like to disable ALTQ