There is nothing public. Generally we include as a recommended patch anything that can be fixed by a run-time patch, is confirmed as fixed definitively and has significant impact.

Hmm, I wonder how that happened. Curious. Glad you were able to track that down.

@stephenw10
No wireguard in my case. Now I use PPPoE only for IPv4 and HE GIF for the IPv6 testing and fallback. No problem with 13.x.x.x based sites currently, but I did not tested all of them.
I honestly don't understand what the relation to IPv6 is at all if packet capture shows that the connection is going through the IPv4 stack. I would be sure that it's some configuration error either from the provider's side or somewhere else on my end, but in fact, everything works directly, without pfSense.

To get a working internet connection we must create a VLAN7, assignee it and add a PPPoE connection. I wouldn't say this is impossible, but if one character is wrong and the installer try three times to connect my ISP blocks me for some hours...

@lightingman117 It feels like asking for trouble if you install unsupported packages inside pfsense... I am running pfsense as a VM under Proxmox which has worked fine for a few years now. With such a setup you can run any number of additional "packages" as separate VM's on the same machine, all booting up and working in unison.
Such a setup should work perfectly fine on a Protectly machine...

I then have AdGuard Home running as a VM and simply set all DHCP clients in pfsense so that their DNS is the AdGuard IP. AdGuard is not a DNS resolver, just a blocker/filtering service so it needs to point to a DNS service. You don't need to use pfsense resolver (unbound) but you can if you like, simply by setting the IP as the upstream DNS in AdGuard.

Then if you find it useful you can use pfBlockerNG to do additional filtering, like GeoBlocking.

@stephenw10 It was an antivirus page I left up that Squid stopped your right. Thanks I never reset the firewall when that was open.

The "Squid stopped a virus page"

Install snort , untick "keep settings after deinstalling" remove snort again. Looks this msg disappeared

@stephenw10 I will do it, thanks a lot for your patience and your help

Hmm, I have no idea how it's ended up displaying that file there. I've never seen that.

What sort of things were you doing before this happened? Did you add any custom code?

Steve

@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