@johnpoz ~ I also added filter-AAAA to the DNS forwarder's Options so I think I've now killed IPv6 in every way possible on my firewalls! :o) Roy...

@Gertjan thanks you so much 🤟

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