@stephenw10
Got it. Put the config file from the active one on a usb stick and inserted it, powered up the spare with the cable from the cable modem plugged in. Came up and set everything up perfectly.

I really appreciate your help Stephen! Very glad that I now have 2 updated devices, one being a spare should an emergency arise. Thanks again.

I expect that work. Let us know what you find.

What can explain why MS Teams don’t work well on that network? It is the ISP? Or it a miss configuration in pfsense on VMware?

The actual ISP uses a hybrid fibre/coax network, the speedtest was good on wifi and connected with an ethernet cable. Google meet work well, YouTube too, etc. But MS Teams are buggy asf.

If we use MS Teams on another ISP like Telus who use à fibre network, everything works well on the same computer.

It is the ISP fault?

Yup it's very easy to get off track when changing a lot of things at once. I agree with @Jarhead, try to change one thing at a time and verify it did what you were expecting.

Of course sometimes you have no choice but to make several changes and hope it all lines up! 😉

@stephenw10 It worked, friend, thank you very much, I had to configure phase2 as the image I sent last

pkg install will only look in the configured pfSense repo and those pkgs should already be installed:

[24.03-RELEASE][admin@apu.stevew.lan]/root: pkg search microcode cpu-microcode-1.0 Meta-package for CPU microcode updates cpu-microcode-amd-20231019 AMD CPU microcode updates cpu-microcode-intel-20231114 Intel CPU microcode updates cpu-microcode-rc-1.0_1 RC script for CPU microcode updates [24.03-RELEASE][admin@apu.stevew.lan]/root: pkg info -x microcode cpu-microcode-1.0 cpu-microcode-amd-20231019 cpu-microcode-intel-20231114 cpu-microcode-rc-1.0_1

Also if you want to run pkg commands like that you should do so from the CLI instead of having to pipe 'y' to it. That way you can see output and review it before allowing it.
But if you have to use the gui command prompt pkg has a switch for that: pkg install -y cpu-microcode

Steve

Those menu entries are created in the config. I have no idea how you ended up with two but you can remove it from the file if if you need to.

@johnpoz Thank you so much! This helped me to understand and pinpoint the actual configuration responsible for the ARP scan.

@dennypage said in IGMP strangeness:

@stephenw10 said in IGMP strangeness:

As long as the ruleset is reloaded after enabling it that should work fine. Nothing there should require a reboot.

Agreed. Only thing I could think of is that something prevented the reload from completing…

@stephenw10, In the other recent thread, the user indicated that after defining the rule, they needed to perform a state reset before the rule worked. Worth noting. This would also explain the situation with the user who asserted that they had to reboot.

@michmoor hi mich, can you give more detail on what rules you created to allow bgp across the interfaces?
thanks
jim

@bthoven
It worked for me.
Using 'certctl rehash' than 'pkg-static -d update'
Thanks

@johnpoz, hum thats what i thought. I will follow the othere thread and see where I end up.

I appreciate all the guidance and adviae that you have proevided. I jave a good base to start from now.

Yes that is the best way.

For a small edit like this you could likely just edit the config file in place and then reboot.

It's possible if the uninstall didn't complete. Check Diag > System Activity or the output of ps -auxwwd.

The spare 1100 will need a WAN IP that is in your current LAN subnet. I would just use the default for that which sets the WAN as DHCP. It will pull a lease from your existing dhcp server and should be able to connect out.

@Antibiotic said in pfSense hacking:

Is it default deny?

A firewall is what it says : hard to pass through. At least, that was the word they came up with in the middle of in the last century. These days, I tend to think my pfSense has a back hole in front of my WAN, 'visible' from the outside.
With this perspective in mind, why would you block a black hole with 'stop' rules in front it ? Stop signs that say : [first stop rule] no RFC1918 here. And [second rule] unknown flying sorcerers neither.
Just let them have it 👍
As it should be obvious that anything imaginable (by humans) will get into the black hole, and from there its not our problem anymore.
Block rules do use CPU cycles .... why waste cycles on stuff that's going to be annihilated ?
So : no need to block access to black hole. It's a bit 'useless'.

The perfect WAN firewall list is ... an empty list.

There always will be some #d#ts that try to poke in a black hole to see if the can manage to do something with it.
They are just proving that physical laws exist, but they just didn't get that yet.
Using a firewall is actually a responsible social thing to do : its keep #d#ts busy and from the street, as they might be doing other things out there ^^

edit : wait : your stop rules can have a useful function !

This :

50248455-ad9b-4130-b13f-634626b95d5b-image.png

is useful so you can see if there are actually #d#ts out there that send you packets that match, thus hit, the rule.

Your 'Not assigned by IANA' has actually a double score counter : these packets shouldn't even be routed to you by your ISP, so they couldn't never reach you, as "non assigned networks" can't be used / routed on the Internet.
So maybe your on to something : your ISP is also a #d#t 😊

It's a compiled patch so it cannot be applied via the patches package. It will be in 24.07. If we have to produce a point release for 24.03 we could probably pull that in but it's unlikely that by itself would warrant it.

Steve

@stephenw10

30% of 3.7GB.

I started another thread since things have gone downhill a bit.

@stephenw10 Could be, anyway this error does not appear anymore.

It's common to have the SWAP as double the RAM size. That way you can dump the full ram to it if required. pfSense doesn't do that though.