I assume 192.168.20.1 is the pfSense LAN IP? It would only send an ARP request for 1.1.1.1 there if it thinks it has an IP in the same subnet as that. So at least when it was sending that ARP request it must have had a bad route present somehow.

The interrupts are expected and shouldn't be a huge issue at that rate. You could just be seeing some saturation. Check Status > Monitoring for the traffic on WAN and LAN. Is it hitting the available bandwidth?
You may need some shaping prioritise remote desktop.

Steve

@darkcorner said in pfsense 2.7 menu stuck with NUT crash:

I wouldn't even know where to configure console protection with a password. So the answer is, no, there shouldn't be.

It's a checkbox in System / Advanced / Admin Access.

Screenshot 2023-10-03 at 07.56.17.png

It's quite likely something you set and didn't think too much about at the time. It's in a bunch of pfSense HowTos.

@michmoor said in Simple question about KEA DHCP:

@jimp Based on notes in the ticket is it expected to arrive for 23.09?

That's the plan, but as stated there it is working for IPv4 and not IPv6, so it may not be 100% in 23.09. Keep an eye on the Redmine to know for sure.

@Cabledude TAC ticket opened.

@Gertjan Thank you.

The requirements are Port 587, Auth method is Plain, with STARTTLS

@SteveITS I've just tried it again, without Enable SMTP over SSL/TLS or Validate the SSL/TLS certificate presented by the server enabled, and it worked...

I thought I'd tried that earlier and it failed, not sure what I've tried now, been messing about with it for so long :)

But thanks everyone, all good now.

Yup, tailscale should do that for you.

@stephenw10 You did ask i must have misunderstood, my bad on that. But good to know its expected behavior.
Thank you so much for the assist here. Appreciate it!!

@stephenw10 said in APu1C latest BIOS?:

@joea said in APu1C latest BIOS?:

I found a windows version of the installer

Not entirely sure what that would be. flashrom is a FreeBSD pkg that we have in our repo. For reference you can install it in pfSense at the command line if it's not already:
pkg-static install flashom

Anyway glad you were able to get the BIOS flashed. 👍

Ah, my description was poor, probably should have turned in by that time. It was actually a means to create, via Windows, a bootable USB stick to perform the flash.

I found the "windows installer" here: https://pcengines.ch/howto.htm#TinyCoreLinux

Thanks for the additional info.

@stephenw10 that could be failure to the captive portal - but that means they have already joined the wifi network.

Ok fixed solved this is an apple keychain problem.

I deleted the keychain and re-entered the password.

@stephenw10 Well I ended up finding a used cheap 4860-1U to use for the time being, and the console feature worked using the same cable and computers that the other one would not work with. So my guess is I had a hardware failure.

@stephenw10 Hmmm, I will have to wait it does it again..
Thank you for taking the time, and I will report back the next time it does it.

Can we assume you don't have a note of the ACB key then?

@stephenw10

Ugh... missed an interface on the DMZ. It's a /27 routed through the WAN. There was a virtual IP assigned which was acting as a gateway for the network behind it. I failed to manually block the admin ports.

Thanks for helping me with my troubleshooting gymnastics!

@stephenw10 ok thank you I will try🙏🏼

If nothing was changed in pfSense in between those connection attempts then the difference is that it succeeds when pfSense initiates the connection:

Sep 27 14:02:48 charon 18669 09[IKE] <con2|5> initiating Main Mode IKE_SA con2[5] to 200.0.211.137 Sep 27 14:02:48 charon 18669 09[IKE] <con2|5> IKE_SA con2[5] state change: CREATED => CONNECTING Sep 27 14:02:48 charon 18669 09[CFG] <con2|5> configured proposals: IKE:AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024 Sep 27 14:02:48 charon 18669 09[ENC] <con2|5> generating ID_PROT request 0 [ SA V V V V V ] Sep 27 14:02:48 charon 18669 09[NET] <con2|5> sending packet: from 190.13.88.176[500] to 200.0.211.137[500] (180 bytes) Sep 27 14:02:48 charon 18669 11[NET] <con2|5> received packet: from 200.0.211.137[500] to 190.13.88.176[500] (104 bytes) Sep 27 14:02:48 charon 18669 11[ENC] <con2|5> parsed ID_PROT response 0 [ SA V ] Sep 27 14:02:48 charon 18669 11[IKE] <con2|5> received NAT-T (RFC 3947) vendor ID Sep 27 14:02:48 charon 18669 11[CFG] <con2|5> selecting proposal: Sep 27 14:02:48 charon 18669 11[CFG] <con2|5> proposal matches

But fails when the other side is initiating:

Sep 27 14:02:43 charon 18669 16[NET] <4> received packet: from 200.0.211.137[500] to 190.13.88.176[500] (168 bytes) Sep 27 14:02:43 charon 18669 16[ENC] <4> parsed ID_PROT request 0 [ SA V V V V ] Sep 27 14:02:43 charon 18669 16[CFG] <4> looking for an IKEv1 config for 190.13.88.176...200.0.211.137 Sep 27 14:02:43 charon 18669 16[IKE] <4> no IKE config found for 190.13.88.176...200.0.211.137, sending NO_PROPOSAL_CHOSEN

So there is probably some difference between the configs. For example if the other side is set to IKEv1or2 it may be defaulting to v2 when it proposes but allows v1 when pfSense proposes it.

If the other node is not running the same version then config sync will be disabled. But state sync would still be enabled. And the CARP status doesn't care about the version.

It could be related that bug, though I don't see the same flood of CARP events that triggered.

It depends who/what the users are. If they are real people they usually let you know pretty quick when things don't work. 😉

If it's IoT devices etc you have to test yourself.

As with all things it's a question of security vs convenience. Though the actual security benefits are questionable at best and the inconvenience is significant so.....