@chudak Just popped up on my 6100 as well today

@rcfa They support ARM on Amazon: https://docs.netgate.com/pfsense/en/latest/solutions/aws-vpn-appliance/ I have no insight into Netgate's plans of course, but so far ARM support has been for Plus so I don't expect a CE ARM version if that's what you're asking.

but i guess i wrong to figure what is ok for dns leaking and what isnt for dns leaking i just tried to make sure the tests showed i wasnt leaking

@stephenw10 Hi Stephen, thanks for the reply - I wasn't sure when posting whether prompting to choose interfaces if there is a mismatch and automatic package re-installation were expected to happen (and therefore I'm seeing a bug) or whether ACB restores don't implement this functionality. When I do a manual restore via a manually saved local backup it does detect interface device name mismatches and give a chance to correct them and also does trigger automatic package reinstallation after a reboot, but neither of these seem to happen when restoring an ACB, you just get a prompt to reboot, and if you follow that advice you can easily reboot to a partially broken system where interface naming has to be fixed at the console and packages have to be reinstalled one by one. The interfaces on the original hardware are ix0 for LAN (with 12 VLAN's attached to that) and ix1 for WAN. Both are ports on a dual port 10Gb intel Fibre PCI card. On Proxmox, which was where I initially restored to in a hurry, the interface names are vtnet0 for LAN and vtnet1 for WAN using VirtIO paravirtualized adaptors. On Hyper-V on migration two the interfaces in a Gen 2 machine are hn0 for WAN and hn1 for Lan, and the same issue happened there. In both cases the absence of ix0 and ix1 should ideally trigger a warning that ix0 and ix1 don't exist and offer for me to remap them. I get the impression that ACB restores currently assume you are restoring a configuration backup to the same hardware and that required packages are already installed - in other words that you're only doing a configuration rollback not a fresh install or a hardware migration. But when you restore onto a fresh installation on the same hardware you're going to hit the issue that packages are not reinstalled automatically, and if you have to restore on different hardware you're also going to hit the interface naming issue. At the end of the day it's not a huge problem now that I know about it - just decline the reboot prompt, reconfigure network interfaces in the GUI, reboot, then install packages manually. But it feels like it could go more smoothly than this - and ACB does allow you to paste in the secret from your old installation to recover backups onto new hardware, so it seems at least some thought was given to restoring ACB backups on new hardware. I will be doing the reverse - restoring back onto original hardware soon, possibly tonight or tomorrow as I am expecting replacement SSDs today.. Previously it was a single SSD, this time I'm going to configure two in a ZFS mirror... even though there are no hot swap bays to swap a faulty drive without a power cycle (small 1U rack server without front drive bays) it will still be better than a single point of failure and give me time to put a standby virtual machine in place to cover the downtime needed to swap a failed drive in the unlikely event it happened again... For anyone curious, the failed drive is a Crucial MX500 2.5SSD (CT250MX500SSD1) which is running the latest firmware - it has failed in a READ ONLY state where it is impossible to write to, but can still be read and even firmware version can be queried. The PFSense console log was full of errors reporting unable to write, and this was confirmed plugging it into another PC which also can't write to it, either under Windows or even running Spinrite. Oddly, Crucial storage executive under Windows says the drive is fine despite the fact that nothing can write to it!

@stephenw10 said in Subnet Mask Update: You need to set the subnet mask on everything static in the subnet. You probably still have somethings set to /24 creating route asymmetry when they try to use their gateway instead of sending directly. Everything appears to be working correctly now. I think this was it. I have an UnRaid server that I thought I changed the subnet mask but it didn't change. Actually have to stop the array and change it. After doing this, I'm back in business!

You can just set the log level to query info in the Unbound advanced setting tab.

Safest way is to backup the config from https://<your-firewall-ip>/diag_backup.php. Edit it then restore the config. That way pfSense will refuse to import it of you have typo'd something. Look in the config for the widgets section like: <widgets> <sequence>system_information:col1:open:0,disks:col1:open,interfaces:col2:open:0,services_status:col2:open:0,gateways:col2:open:0,snort_alerts:col2:open:0</sequence> <period>10</period> <gateways-0> <descr><![CDATA[Gateways]]></descr> <display_type>both_ip</display_type> <gatewaysfilter>WAN_DHCP6</gatewaysfilter> </gateways-0> </widgets> Remove the disks widget. So there I would remove: disks:col1:open, But the widget should be fine with just a ZFS mirror. What do you see from?: zfs list; mount -p; geom disk list;

Ok that will be useful. Also see if you can try running a dtrace whilst sending a failing large ping. So you'll need two ssh sessions open it, for the trace and for the ping. In the dtrace session run: dtrace -n 'fbt::if_inc_counter:entry / arg1 != 0 && arg1 != 2 && arg1 != 5 && arg1 != 6 / { printf("%s type %d count %d", ((struct ifnet*)arg0)->if_xname, arg1, arg2); stack(); }' Then send some large pings in the other session that should work but fail. Stop the dtrace with ctl+c after a few pings and see what's shown.

@azalea said in IPv6 Link Local in Interface Status: On the other hand, the OPT1 interface status display, NDP table display, and ifconfig execution results all show that the OPT1 interface (IPv6) is linked to "fe80::XXXX:XXXX:XXXX:XXXX%pppoe1 From the Wikipedia article: Even if a single address is not in use in different zones, the address prefixes for addresses in those zones may still be identical, which makes the operating system unable to select an outgoing interface based on the information in the routing table (which is prefix-based). [In this specific case, your WAN interface's link-local address of fe80::[EUI-64]/128 is the 'prefix' being referred to here] In order to resolve the ambiguity in textual addresses, a zone index must be appended to the address. [ . . . ] As multiple interfaces may belong to the same zone (e.g. when connected to the same network), in practice two addresses with different zone identifiers may actually be equivalent, and refer to the same host on the same link. fe80::[identical EUI-64]%ppoe0 and fe80::[identical EUI-64]%em0 are obviously not mutually exclusive addresses, even if both or neither are active at any given time on a given link. And the zone index in general can obviously refer to both, a physical or a logical network interface. The same goes for fe80::[identical EUI-64]%ppoe1 and fe80::[identical EUI-64]%em1 on the OPT1 interface. Agreed no problem here, just thought-provoking discussion (at least for me!) of an interesting IPv6 feature.

Ah, interesting. Yup AT&T expect to see their own router at the end of GPON/XPON and pfSense could well be doing something that doesn't play well. Obviously it still shouldn't panic like that. The panic appears to be caused by a race condition during removal of an IPv6 address. If the WAN was renewing a lease repeatedly that seems likely.

So you upgraded the secondary to 25.07 and it didn't hit the same issue?

Hmm, well it should start at boot. If it fails to start I'd expect some error to be logged.

You could try an afterfilterchange shellcmd to trigger a script. That would be triggered when any tunnel comes up.

Hmm, OK. Not much to go on in that report unfortunately. If it does crash again comparing it would be useful. I'll see if anyone else sees anything I'm missing.

@stephenw10 It's still showing a few simuleanteously, but every minute or so, not every other second like it was before.

You have to assign the OpenVPN client as a new interface so pfSense sees it as a WAN. It will then create a dynamic gateway for it you can use in a policy routing rule.