@Laxarus Thanks for the help my friend. It helped me a lot!! After 12 hours of migrating 4 domain controllers, I almost hit the rollback button until I saw your tip. I tried this and it worked for two systems that had problems. The only two systems that we could not test in our lab environment.

@roben1000 See here : I RESTART THE PFSENSE BECAUSE OF THIS NOW I CANNOT ACCESS IT

We may be able to recover the old key if you send me the NDI or hint in chat.

Aha, that would do it! Easy mistake, we've all done stuff like that.

If you have a legitimate reason to need to migrate the NDI then we can accommodate that. If you had a hardware failure for example. Or, here, if you upgraded and found your new hardware is incompatible. We're not completely inflexible.

https://docs.netgate.com/pfsense/en/latest/recipes/virtualize-proxmox-ve.html

@viragomann, thank you very much for your help!

@LaUs3r I am experiencing the same even on the latest pfSense Plus beta version (25.03)

@stephenw10 Thanks again. I've submitted a correction suggestion to MaxMind for the IP. I assume that the regular scheduled auto updates of pfBlocker databases within my pfSense also update Maxmind's free GeoIP database as well -- I noticed the free GeoIP database is updated by Maxmind every month. Cheers

@johnpoz getting a squid transparent proxy running on pfsense with ssl/mitm from scratch wasn't easy tbqh (but maybe that's another topic...) it is quite satisfying though to see the RT access logs flow in pfsense, and the secure lock in the browser at the same time (= [image: 1747930627954-squiddie.jpg] but still, as you mentioned before, without the device accepting my ""internal-ca"", it's besides the point

There is, here: https://redmine.pfsense.org/

Are you able to test in 25.03-Beta?

I have seen it happen in the past when the change is initially made. Somehow the dhcp server is still running on the interface. But not for a while and not beyond the initial switch.

Well from what we've seen here it is googles fault. Cogent is not preventing you use other DNS servers. What's happening is that Google's servers detects you are resolving DNS from a different location than you're are sourcing requests and flags the connection as suspicious in some way requiring additional screening. The same way that some sites will do that for VPN connections. A "DNS leak" is one way sites detect it. The interesting thing is that they only flag the Cogent connection that way. One other thing you could do VPN all your traffic over the Cogent WAN to the same location you are resolving from. But I would at least try resolving locally first since that would also set the DNS and source IPs to match. With DNSSec enabled you can be pretty confident in the results. Using DoT really just outsources your trust to cloudflare.

@BigTulsa Exactly. Allows me to run with 1 less piece of equipment and a few less cables. XGS-pon on one end and regular 10Gb SFP on the other end. My 7100 is happy with it. It does get hot, so I have a 20mm USB powered fan cooling it. Now I have a use for one of the USB ports on the firewall. You do need to keep the ATT router ready to power up, it would be best if it is up if you have a problem.

@stephenw10 Excellent thank you.

24.11 changed something. New code: $username = 'foobar'; $user_item_config = getUserEntry($username); $usernum = $user_item_config['idx']; $user = &$user_item_config['item']; $user['authorizedkeys'] = "base-64-encoded-string-here"; config_set_path('system/user/'. $usernum . '/authorizedkeys', "base-64-encoded-string-here" ); write_config('edited SSH public key for user foobar via pfSsh.php'); local_user_set($user);

Usual suspects are some browser plugin blocking a script or similar. Though I've never seen that particular behaviour before.

@johnpoz Ok, thank you. So to avoid any possible side effects by doing some exotic settings mentionned in your post, I decided to follow the "ocd monkey gone with simple click" suggestion. Thank you all.

@dutsnekcirf said in Can the "Auto Configuration Backup" Device Key be recovered from the CLI?: how should I copy that directory back onto the box from my usb drive? Install pfSense using the installer. Accept all values 'by default', so you can go as fast as possible. As soon as the GUI becomes alive, login, and import the latest backed up config. Have it reboot - and during reboot it will set up your LAN 'as before' a,d your WAN 'as before' - and all interface if you had any. Because WAN is now fully operational and you had probably some packages installed, it will fetch them, and set them up. This can take a minute or two. When that's done, for good manner, from the GUI, do a fill reboot again. If you really want to, you an now insert the USB drive with all the files have kept on it, mount the USB drive, and copy (/cf/conf/backup - see below) them in place. Just keep in mind : check what happens afterwards. Normally, the files located in /cf/conf/backup/ are maintained by pfSense. Dono what happens when you copy files in there. The content of /cf/conf/ : don't touch / add / remove anything from that place, let pfSense handle it. Or create a new folder below the /root/ folder, and put them there. Or don't copy anything, keep the saved files on another place, like the USB drive, as that will be the best place : not on pfSense itself, but another device.