@bimmerdriver said in Questions about log messages:

The inbound messages are all mangled the same way: fe80:5:: as opposed to fe80::.

The outbound messages are all mangled the same way: fe80:6:: as opposed to fe80::.

Both fe80:5::/128 (i.e., fe80:0005:0000:0000:0000:0000:0000:0000) and fe80:6::/128 (i.e., fe80:0006:0000:0000:0000:0000:0000:0000) are valid IPv6 host addresses and are within the fe80::/10 link-local reserved address block (i.e., fe80:0000:0000:0000:0000:0000:0000:0000 - febf:ffff:ffff:ffff:ffff:ffff:ffff:ffff).

So what will definitely happen here is that the NDI, which is calculated from the hardware at boot, will change because pfSense now sees different NICs in the system. That means it will be unable to connect to the pkg system to check for update etc which may cause some slowness on the dashboard which runs an update check by default. But that shouldn't cause any dramatic slowdown.

If you restore a config in that situation it will be unable to reload packages will could cause problems.

I can usually migrate the registered NDI to the new value one time one you have the final hardware config in place.

@rpm5099 said in Complete Fail replacing NIC:

However, it inexplicably causes all kinds of other bizarre issues with pfSense seemingly unrelated to interfaces at all.

Like what? Anything other that slowness in the gui?

Thanks for the reply Steve

Saving the key is clearly stated, which I did not do.

I assumed restoring a local backup would have said information.

However, looking through the config file, I see the password is saved in plain text.

Hmm so it did appear to upgrade to 24.03 patch 1?

You might have a filesystem issue that cannot be fixed by the normal processes that run at boot. It's also possible you have an issue with the eMMC drive.

Try checking the eMMC status: https://docs.netgate.com/pfsense/en/latest/troubleshooting/disk-lifetime.html#emmc

If that looks OK then I'd try backing up the config and re-installing 24.11 clean: https://docs.netgate.com/pfsense/en/latest/solutions/sg-1100/reinstall-pfsense.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 (=
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.